Unit Testing

Each unit or module should have a test harness that exercises the public interface to the unit, and any significant internals. If the unit is complex enough, the test harness may need access to private member functions and private data structures; although this could be a hint that the unit should be split. The test harness should be written with knowledge of the internals in mind, to ensure that it stresses the algorithms and data structures as much as possible.

It is desirable for the unit test for a given unit to link against the code for other units on which it depends. So if unit A calls a function in unit B, the unit test for unit A will end up including unit B. This is a good thing, because it helps facilitate progressive integration during development. Many developers develop stub units for unit B in a situation like this, but I would only do that if unit B hasn't been written or isn't ready yet. Unit testing with assertions is important, because this sort of testing will catch cases where unit A is mis-using the unit interface to unit B.

Higher level units in the system will be dependent on many other units, the higher you go the more powerful combining integration testing and unit testing becomes. Unit tests at the system level become the system test. I'm assuming that your software architecture is reasonably hierarchical, and looks more like a tree than an undirected graph. A spaghetti architecture will be difficult to integrate, test and develop with. Then you might be tempted to generate stubs just to keep the unit test dependencies under control; but it would be better to adopt a cleaner architecture where unit dependencies only flow in one direction.

To get the most benefit from unit testing, you should also use assertions liberally, build your unit tests into a regression test suite that runs all the unit tests sequentially from the bottom up, and run the suite before every check-in and as part of your nightly build and test mechanism.

---

Social Bookmark this page: