Our team aims for at least 70% code coverage with our unit tests. I've read that quite a few people only test public methods as the private methods will eventually be reached this way. From my experience this isn't always the case.
We use Visual Studio 2008's built in unit testing framework. The nice thing about this framework is that it's integrated into the IDE and simply right-clicking on a method or class will bring up options to create unit tests. Along with this, accessor classes are created so that you have access to private fields and methods.
I test both public and private methods just to be exhaustive. Sometimes I run into conditional statements that I can't test fully without the class accessors. I've hit 80%+ code coverage on my current project, but I will be looking into white to test the UI in my project as well. This will certainly boost code coverage.
Order matters in unit tests. For example, I have classes that depend on other classes to work. The unit test stubs that get inserted by the IDE do not account for this, it merely gives you a very trivial skeleton. It is up to you to make sure that you have all of the dependent classes instantiated before testing the class that you actually want to test.
No comments:
Post a Comment