Chapter 4. Unit Testing

If this project handbook would have been for a professional project (with professional I mean, a project that people make money with), I would have written

Caution

Unit tests must be supplied by the developer with the classes/source-code he checks into the repository!.

Since this is the handbook for a voluntary work (which is not less professional than any other project), I replace the above sentence with

Note

Each developer in this project is strongly encouraged to develop unit tests for the code he or she develops and make them available to the project team!.

4.1. Why unit testing?

Before I can give an answer to this question, I should explain what unit testing is about. I do not cover all relevant aspects here nor do I start a discussion of the various aspects of unit testing. If you want to read more about the details of unit testing, the philosophy behind it and about the various tools available, please visit the project pages of JUnit and CPPUNIT. The following explanation describes what unit testing is:

For each class developed in a project, an accompanying test container is developed when the interface of the class is defined but before the implementation of the class starts. The test container consists out of testcases that perform all necessary tests on the class while verifying the results. One or more of these test containers (for more than one class) form a test suite.

Your might think, that it is strange to first define the interface, then develop the tests and then start the development of the actual code, but it has shown, that this approach has a couple of interesting side-effects:

Now, the list of all these side-effects is actually the answer to the question Why unit testing? or does anyone have a argument against it? I agree, that in some cases automated unit testing is hard to achieve (e.g. for GUI related code) but I found, that whenever it is possible to introduce automated unit tests, the benefit is huge.