TDD Unit Testing Tool Features
Just about any tool you consider will work for Test-Driven Development. Some tools make it easier, however, and some contain features that make TDD into more of a chore. Many tools contain additional fancy bells and whistles that you’ll probably never need when doing TDD. Some tools have different design considerations, such as a minimal footprint, and as a result may include features that clash with the goals of TDD.
I consider the following features to be “must haves” for doing TDD:
| Discrete test names |
The tool should support the ability to identify tests uniquely, preferably using a combination of a scoping/grouping name and a test name. At least one tool supports test names only as an afterthought, by default providing only numbers for a test. |
| Ease of adding new tests |
Tests should automatically register so that they are executed by default. The tool should not require the programmer to separately register a defined test. Older tools such as CppUnit require programmers to explicitly register new tests with a suite. |
| Fixture support | The tool should provide the ability to define fixtures that provide setup/teardown hooks, as well as the ability to group common test helper functions. |
| Isolated tests | The tool should support the ability to easily ensure that each unit test can run with no dependency on the outcome of any other unit test. |
| Equality assertions | The tool should provide the ability to compare two quantities and produce clear, expressive failure messages. |
| Test suites | The tool should support the ability to easily execute arbitrary groups of unit tests. |
| Mocking support | The tool either should directly provide support to simplify the effort to define and use mocks or should support working in conjunction with a third-party mocking tool. |
The following features may enhance your test-driving experience but aren’t essential:
| Hamcrest | The tool should provide an enhanced assertion facility that supports matchers (and the ability to define custom matchers). Sustaining TDD requires highly readable tests, and Hamcrest can aid in this goal. |
| Customizable output | The test tool should provide the ability to easily customize test-run output. By default, the tool should provide a simplified summary view showing only test failure detail. |
| Exception assertions | The tool should provide a direct means of asserting that an exception was thrown. |
| Test execution statistics | The tool should provide summary statistics on the test run and should provide times for each individual test execution. |
| Memory leak testing | The tool should support the configurable feature of failing if memory was allocated during execution of an individual test but not released. |
| Robustness | The tool should provide the option to complete an entire test run even when unexpected exceptions are thrown or the application causes a crash. (This feature is more useful when running tests in a CI build server than it is when test-driving.) |
The following features may sound nice but are irrelevant for the purposes of practicing TDD:
| Parameterized tests | You might find a rare case where having the ability to slam a bunch of data against a single test is useful. It is not, however, a test-driven practice, and it’s reasonably easy to code on your own if necessary. |
| Dependencies | For integration tests, it can be highly useful to be able to force an order of execution. Creating tests that are dependent upon the result of others, however, has nothing to do with TDD. |