With the advent of unit test frameworks like JUnit, NUnit, MBUnit, ... and the new Visual Studio Team System a plethora of articles and books spread the news that unit tests are a nice thing in every programmers toolbox. We all know that solid software engineering requires a certain amount of testing. Everybody knows it and only few actually do it. This might have to do with pressing time schedules and human laziness which most programmers follow: Achieve good results with the least amount of work. Additional testing does not seem to spare work but generates new one. I can't deny that fact but to point out that it is often overlooked that quality will go up right at the beginning of your project. This can help you to reduce your stress level when the release date comes nearer and you are confident that you have squeezed out most bugs of your code base. One relatively new methodology is TDD (Test Driven Development).
At MSDN there was content which did not describe real TDD. The content has been removed and is reworked at the moment. The essence of TDD is that your code and tests evolve continuously during development. It is not a waterfall model where you define at first all your test cases, then create your code and never look back what you could have made better or (even worse) have missed. Instead you define at first the requirements and design upon your current knowledge the test cases which are the easiest to implement and watch them fail. Now you can implement the desired functionality and have your first green light in your unit test. Look at the code see if it is well designed and move on to the next feature you want to implement a test case ... look back, refactor and so on. A very informative blog about TDD can be found here.
With .NET 2.0 a very nice attribute was introduced to enable you to create separate test assemblies (contains the unit tests) and functional assemblies (the code to be tested) more easily. With the separation of testing and production code you face the problem that you cannot test classes and data types which are marked as internal in the functional assemblies. What you really would like to do is to allow your test assemblies access to your internal types. This is exactly what InternalsVisibleTo attribute allows you to do.
[assembly: InternalsVisibleTo("YourTestAssemblyName")]
Lets hope that this attribute will be always so simple. There are critical voices out there that fear that you should be forced to sign the test assembly to prevent the creation of fake test assemblies and use the internal types in a not intended way. I do not think that this risk is so big of the following two reasons:
- You can always inspect other types by using reflection.
- Lutz Roeders Reflector will find anything you every wanted to hide anyway.
Use unit tests and your stress level will decrease after the shipment date of your product because fewer customers will complain about the same obvious bugs which should have been found during the development cycle. At unit test level it is a red light on your screen, after shipment it is a angry customer and a big red light on your managers screen...