Should automated unit tests be a part of the build process, or should they be manually run when someone makes changes to the code instead?
To me it seems like making it part of the build rather than leaving it a manual process has some clear advantages. Running your tests with the build would make them run more frequently and would keep them from getting of sync with the code.
The downside to running them with the build is that it would increase build times and could cause a build to fail, but I was under the impression that tests that take more than a couple hundredths of a second to complete are not good tests. Also if a build fails because of a test wouldn't that be a good thing? It would keep you from deploying broken code.
I don't see many people making the tests run directly as part of the build so I'm wondering why they are usually separate.
Best Answer
Disclaimer: I'm not a purist regarding testing. I like to do my TDD, but I don't think 100% coverage is necessary for all projects.
That being said, the rule of thumb should be "every change must be tested and approved before going to production".
That means you may run your tests after commit (triggered automatically by your continuous integration tool, like Jenkins, TFS or others) or during the build pre-deploy phase.
Personally, I find running tests for every single build I do on my machine boring and easy to make me "drift-off" to other chores while the tests are running.
That being said, no code that goes to production comes directly from my machine, they all go from a CI/Build machine. This guarantees that none of my code has the "Works only on my machine" stamp.
If you have a large team, testing after commit may be a better strategy, to allow you identify early the build-breakers and allow the team recover and communicate faster, but it'll probably need more server resources to do so.
With a smaller and well-oiled team testing pre-deploy to UAT / Production may be enough to guarantee quality.
Just keep in mind some rules of thumb: