Home 

Chapter 6. Unit Testing

Table of Contents

Why unit testing?
Unit testing in KMyMoney
Unit testing HOWTO
Integration of CPPUNIT into the KMyMoney project
Naming conventions
Necessary include files
Accessing private members
Standard methods for each testcase
CPPUNIT_ASSERT
CPPUNIT_FAIL
CPPUNIT_TEST_SUITE
CPPUNIT_TEST_SUITE_END
CPPUNIT_TEST
CPPUNIT_TEST_SUITE_REGISTRATION

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!.

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:

  • The developer spends time to think about how to test his implementation before he actually works on the implementation. This leads to the fact, that while working on the implementation, he already knows how his code will be tested.

  • A clear definition of the end of implementation exists due to the fact, that the testcases will all fail before the beginning of the implementation phase. Once implementation proceeds, more and more testcases will pass. When they all pass, the development is finished.

  • Since the tests will run automated and will be re-run very often during the development cycle, a lot of problems will be caught very early on. This reduces the number of problems found during integration of the project. Believe me, there will be plenty left!

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.