 |
|||||||||
|
|||||||||
|
|
I’ve just finished skimming two great books: Pragmatic Unit Testing in C# with NUnit (Andrew Hunt and David Thomas), and Test Driven Development in Microsoft .NET by James W. Newkirk and Alexei.
These are practical guides that show how to use Unit Testing to ensure that the code actually worked in the first place and fortify your code against regression bugs. Both books refer to NUnit (http://www.nunit.org/), a Unit Testing tool for .Net based on JUnit. I’ll write the next couple blog entries about useful tips I found from these books.
Where to put your Tests: put them in a separate assembly so that they don’t ship with production code. Although if you put them in the same assembly, you can test for protected members, there is a work around: make a test class that inherits the production class, make the new class have public accessors. I use to use the #if DEBUG … #endif, but I like this approach a lot more.
Write the tests first: I use to develop first, and then write tests to cover my back. Test Driven Development is about writing the tests first, they fail (the implementing code hasn’t been written yet), and then write the code to make the tests pass. This makes you program from a user’s perspective (you need to use your own methods to write them in the tests), and gives you a very objective standard to adhere to. You don’t burden yourself with everything that might happen down the road – just make the initial tests pass. Because you should have sufficient tests to cover all the functionality of your program, you can confidently refactor and add features later without fear of breaking things.
Useful checklists (from Pragmatic Unit Testing in C#):
What to test, use your Right-BICEP:
Right
Boundary conditions
Inverse relationships
Cross-Check results with other means
Error Conditions occur
Performance within bounds
Good Tests are A TRIP:
Automatic
Thorough
Repeatable
Independent
Professional
More later
