.NET Unit Testing – Aren’t we talking about code quality… really?

Wow! I have been amazed at the immediate response I have received from my post on unit testing SOA (or other) services. If you have any suggestions or questions regarding unit testing in .Net, please feel free to let me know in the comments. I’ll do what I can to answer your questions. I have been doing unit testing within the VSTS (during its beta releases) and NUnit for nearly 2 years now and have come to a few conclusions that may be worthy of note.
  1. The highest value of unit tests is realized during refactoring and bug fixing/maintenance of an application.
  2. Developers, in solidarity, often fall into the trap of under testing and testing only exepcted program flows (leaving exceptional circumstances tobecome available durig maintenance). The TDD advocates state that writing unit tests gives you a sense of confidence that your code is performing as it should. This confidence can sometimes be a source of overconfidence, leading to equally poor code. Assert.IsTrue(true) (or its many equivalents where a test is effectively not testing any behavior) does not provide much values (save ensuring that the Assert statement is performing as you expect, of course).
  3. Using tools such as NCover or VSTS to ensure 100% test coverage is impractical (not impossible, just impractical) and, as you seek to attain such complete test coverage, ends up with diminishing returns compared to the time invested in writing the tests versus producing production code. A team should decide (if they are using such a tool that measures test coverage) what percentage of test coverage is acceptable. To go along with this, investing most of the testing effort into the most critical components of the system is likely a good thing to do.
  4. Even the Test Driven Development (TDD) people out there will agree that the "T" part (Test) is the most important part. Unless they are very extreme in their views, most will agree that having something at least tested (even after the fact) is more palletable than no testing at all. TDD is a hard paradigm to get your head wrapped around, ensure that you have some tests, whether you wrote them first or as an after-thought.
  5. If you are looking for code quality, have some sort of code review. Be it pair programming or a more formalized code review process, do a code review. A less than adequate test suite won’t give you any more confidence if the code it is testing isn’t well written.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s