Unit tests must be written to test general functionality and boundary conditions. Anything that can break the code should be tested. If there is an uncertainty for a piece of code, we should write a test method. It is better to use judgement while deciding about writing a unit test or not. It is not easy to test GUI. To be able to cover as much code as possible, GUI codes should be kept very small and business classes should be aimed at the tests. It also forces us to keep everything in the business classes and let the GUI do only the presentation work.
What to test:
- We should write test methods for all the public methods.
- Private methods should be tested via public methods. If a private method is very critic we can write a specific test method for it. In VS2005 it is very easy to add a unit test method. Visual Studio itself creates the unit test template using reflection.
- For each piece of requirement we should write a unit test. More than one requirement may be in one public method but usually each requirement represents one possible path in the code and each path should be tested.
-Expected or possible exceptions should be tested as well.
-Before fixing a bug, a unit test can be written first. We can then write the piece of code to fix the issue. It makes us sure that the code is bug-free.
What not to test
-There is no need to test accessors (to getvalues) or mutators (to set values). They are very simple get and set methods. They are unlikely to break the code.
- Unit tests for each class must be placed in a separate test class.
- To test abstract classes implement abstract test classes. Respectively for the concrete classes, concrete test classes inheriting from the abstract ones should be written
- We should write the test methods for dependencies.