4

In one of the projects I am involved with, the team is running a continuous integration/continuous deployment and in development they have a bunch of unit tests as part of the nightly builds.

When this goes to production, they are still running the same tests, every night, even if the code doesn't change and even if they've already been run on dev and then stage.

Does this make sense or should I disable them? The advantage I see is that we have more of identical codebase fordev and production but the downside is the increased load on the server. What do you recommend?

  • Why you are concerned about increased load on the server? – Peter M. - stands for Monica Nov 11 '15 at 16:11
  • 1
    Is the production build always a copy of a successful dev build or is it the result of a merge between 2 or more branches? – L123 Nov 12 '15 at 6:37
2

I would only run the tests on a code change, better on each code change and not just in the night. You want to know which code change broke what test.

In your case this would mean when you branch the code to a production version (which is a sort of code change) you run all the tests one more time and that is it. Only when you hot-fix the production code you run the unit tests again. Deploy only versions that have had all tests run successful.

Maybe some tests function as a sort of monitoring of state or database consistency. I cannot find another reason to run them each night. Maintenance scripts should not be hidden in unit-tests though.

  • 1
    +1 for only doing it on a per-build basis. OP might want to consider a sanity/smoke test for prod if there aren't any other monitors in use. With that you can check critical systems are operational. – kirbycope Nov 11 '15 at 22:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.