How important are unit tests?

Are you taking full advantage of your unit testing?

A lot of the unit testing that gets done doesn't get done right.  Now, what I mean by that isn't that devs don't know how to test their own functionality (though that's really the subject of another post), it's that they don't know how to perform the test itself properly.  I'm gonna qualify that with a question.  What happens to your unit test code once the tests are done?  And while we're at it let me as you another question real quick.  How many unit tests do you perform on a given scenario?

The reason I qualified myself with those 2 questions is because they're really at the crux of how you run your unit tests.  How many times do you run a scenario test?  The answer is that typically you should run it many times.  And of course the reason you should run it many times is to make sure all the kinks are worked out of not only the running of the code itself, but also in the config.  When I run my unit tests I always try to run them on several systems just to make sure I know what I'm gonna have to do to make it work.  And the way you code a unit test that you're going to run again and again is completely different from the way you'll code it to run only once.  I've seen all too many times when devs config a test to run only once.  They typically forget something and they have to make a tweak to either the code or to the environment.  Then they forget something else and they have to make another change.  And they keep going like this until it works.  The problem is that just doing the test once doesn't build solid code.  If you were going to run it several times you would fix your scripts as you went along and they would be very robust.  They would check for environmental changes and other gotchas.  You would make the changes to your script, and try again.

And this brings up another good point about your scripts.  You should always include code to completely reset your environment.  That's what allows you to run your scripts again and again because you've got the code that also resets everything.  And now we're getting into the crux of the first question I asked above.  What happens to the unit test code once the tests are done?  Well, if you've coded the test properly by including all the tweaks needed to make it run on all the different servers you tested on, then your unit test code very easily turns into your production deployment code.  That's the problem with only running a test a single time because you tend to assume it'll work and when you run the prod deployment things go wrong.  But if you've run it several times and tweaked your code each time, you know what to expect in prod and you greatly reduce your chances of having a catastrophic error.

So writing solid unit tests and testing them properly actually saves you time because you can typically turn that code directly into deployment code.  And the system feeds itself because as you make changes to the same apps during different release cycles, you build these libraries for effective testing, and resetting your environment.  So a lot of times you don't have to even have to write that code again, or at least you only have to make very small changes.  So take the time to do your unit testing properly and code-in all your tweaks and resets.  You'll get so much more done and your deployments will go much smoother.

• Microsoft
• Data Center
• testing