2 typographical errors
source | link

I've personally done this with considerable success. The key factors for success:

  • Get (tentative) management support. The advantages of automates tests are well-doccumenteddocumented and should convince any manager to at least try it. That includes finding a spot in the VCS and a build server, because
  • Automated tests only provide their full value if they are run frequently and automatically so that you know about problems soon and don't have to rely on people not forgetting to run the,them. You need a build server that runs them at least daily. This can be an old workstation. Jenkins takes very little work to get running.
  • Lead by example. Write tests, talk about the benefit they're providing to you, and when they reveal errors introduced by other developers talk about it in terms of how they were protected from potentially much greater embarassmentembarrassment.
  • Go for the low-hangighanging fruit. Some parts of the application will be hard to test, others easy. Some will be robutsrobust, others brittle. Writing tests for brittle, but easy to test parts provides the most value in the shortest time.
  • See if you can write reusable tests, e.g. that test conventions or features that all modules (webpagesweb pages, REST services, whatever) must have but which is often forgotten.

I've personally done this with considerable success. The key factors for success:

  • Get (tentative) management support. The advantages of automates tests are well-doccumented and should convince any manager to at least try it. That includes finding a spot in the VCS and a build server, because
  • Automated tests only provide their full value if they are run frequently and automatically so that you know about problems soon and don't have to rely on people not forgetting to run the,. You need a build server that runs them at least daily. This can be an old workstation. Jenkins takes very little work to get running.
  • Lead by example. Write tests, talk about the benefit they're providing to you, and when they reveal errors introduced by other developers talk about it in terms of how they were protected from potentially much greater embarassment.
  • Go for the low-hangig fruit. Some parts of the application will be hard to test, others easy. Some will be robuts, others brittle. Writing tests for brittle, but easy to test parts provides the most value in the shortest time.
  • See if you can write reusable tests, e.g. that test conventions or features that all modules (webpages, REST services, whatever) must have but which is often forgotten.

I've personally done this with considerable success. The key factors for success:

  • Get (tentative) management support. The advantages of automates tests are well-documented and should convince any manager to at least try it. That includes finding a spot in the VCS and a build server, because
  • Automated tests only provide their full value if they are run frequently and automatically so that you know about problems soon and don't have to rely on people not forgetting to run them. You need a build server that runs them at least daily. This can be an old workstation. Jenkins takes very little work to get running.
  • Lead by example. Write tests, talk about the benefit they're providing to you, and when they reveal errors introduced by other developers talk about it in terms of how they were protected from potentially much greater embarrassment.
  • Go for the low-hanging fruit. Some parts of the application will be hard to test, others easy. Some will be robust, others brittle. Writing tests for brittle, but easy to test parts provides the most value in the shortest time.
  • See if you can write reusable tests, e.g. that test conventions or features that all modules (web pages, REST services, whatever) must have but which is often forgotten.
1
source | link

I've personally done this with considerable success. The key factors for success:

  • Get (tentative) management support. The advantages of automates tests are well-doccumented and should convince any manager to at least try it. That includes finding a spot in the VCS and a build server, because
  • Automated tests only provide their full value if they are run frequently and automatically so that you know about problems soon and don't have to rely on people not forgetting to run the,. You need a build server that runs them at least daily. This can be an old workstation. Jenkins takes very little work to get running.
  • Lead by example. Write tests, talk about the benefit they're providing to you, and when they reveal errors introduced by other developers talk about it in terms of how they were protected from potentially much greater embarassment.
  • Go for the low-hangig fruit. Some parts of the application will be hard to test, others easy. Some will be robuts, others brittle. Writing tests for brittle, but easy to test parts provides the most value in the shortest time.
  • See if you can write reusable tests, e.g. that test conventions or features that all modules (webpages, REST services, whatever) must have but which is often forgotten.