Unit Testing in a Managed Environment – The Bare Necessities

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.

  • Soon Hui

    Great post.

    My situation is this: every developer has his own csproject files, and this make merging them somewhat hard. Not only that, the integration tests take 3 hours to run.

    Guess there is no way for me to do continuous integration, though.

  • Ohad

    Soon,
    How about taking the time needed to merge the project files (how long should it take one, two days week?) and than run the integration tests in nightly build while the unit tests will run each check in.

    I think that in that case stopping the daily development race and taking the time to make the development environment better will pay off down the line.

  • Gil Zilberfeld

    Soon Hui,

    Ohad is correct.
    You need to optimize your situation. In the continuous integration cycle, do the compilation and unit tests only. You have to have quick feedback.

    The integration tests can run on a nightly cycle, so you can come to work in the morning and see the result. Automate whatever your can.

TOP