In my last post, I detailed the process of writing the first unit-test. So now you got your fingers dirty, and you’re confident. Now you want to start unit-testing in a more managed, process-oriented way. How do you do it?
Let’s say, for example, you have Team System in place, and you use it for source control and tracking work items. Obviously, you can do much more with Team System, but let’s start with the basics. You’ve tasted enough unit-testing to feel that everyone can benefit from them. Where would you start?
Here are my thoughts. This is what I would consider the essential setup to start with.
- Check in whatever tests you already have, and start checking in any new test code. You don’t want to lose what you already have. Even if you don’t have a continuous integration system in place (see the next step), you can run the tests manually on your (or any) machine anytime.
- Use a continuous build system. In Team System it’s Team Build, or you can use CruiseControl.Net, TeamCity, or any another tool. Whenever someone checks in code, the build starts automatically and reports success/failure. Without running the tests, it would just give a compilation status report, which is a good starting point. The entire build process, from beginning to end should be automatic, and should not have anyone intervening, or fixing just one thing to work. Think of it as a pulse of the project. If the build fails, fix it pronto. Don’t let the poor team lose it’s pulse.
- Add to the build script (or integration script) running of tests. Any automated test should run within the build cycle. The build report should report the results of the tests.
- Make a habit of looking at the test report. If the build fails because of test failure, consider it good feedback. It motivates you to do something – fix the test, change it, delete it, or even ignore it or leave it there. You need to be aware of the test results. From there you can improve.
Once you have this setup, you can now start improving other stuff, like say, prioritizing or tracking your progress. In the next posts, I’ll discuss what to track, and how to manage your unit-tests within a process.
