Unit testing may be extremely useful if we do it right – if. On the other hand, if unit testing
is being used inefficiently, it can be a huge waste of time and effort.
When we were beginning to unit test our T-SQL more than
three years ago, we wrote a series of articles describing how to do it with C#
and NUnit. This approach worked out really well for us, and the effort spent on
building our test harness paid off really well. However, when we were
describing our approaches, we concentrated on how we did it, without too many
explanations on why we made the choices that we made.
After unit testing my T-SQL for more than three years, I decided
to describe the same approach from a different angle, explaining why and when we
want to unit test T-SQL, why we want to test it the way we do, when unit tests
really shine, and when they are all but useless.
When we develop unit tests as part of normal development
cycle, we expect at least some of our effort to pay off – we are less likely to
need maintenance, and if we still need it, proper unit tests will simplify it a
great deal. To get the biggest return on our investment in unit tests, we need
to:
-
Concentrate on situations when unit tests are
most likely to be useful at some later time,
-
Concentrate on situations when developing unit is
relatively easy – go for low hanging fruit first,
-
Develop and maintain unit tests efficiently,
automating routine operations as much as possible,
-
Utilize unit tests as documentation, saving on
documentation and maintenance costs,
-
Make sure everything that needs verification is verified
– if we have loopholes in our tests, we may not notice some bugs,
-
Make sure the test results are presented in an easy-to-understand
way, otherwise we can spend too much time interpreting them.
This is the preliminary plan. Soon it will
expand into a series of blog posts, explaining these ideas in more detail. Here is the next post.