A Pattern Language for Setting Up XUnit Test Fixtures
Gerard Meszaros · 2004
Automated unit tests (A.K.A. developer tests) and functional tests (A.K.A. customer tests) are a cornerstone of many agile development methods (such as eXtreme Programming). The availability of automated, self-checking tests allows developers to be much bolder in how they modify existing software. Almost every test requires some kind of test fixture. The test fixture is everything you need to have in place to run the test. Typically, it consists of objects (in memory or on disk), records in a database, and/or the state of any other depended-on components (or even entire systems or applications) . At first glance, the construction of the test fixture would appear to be a rather simple task. But as t he size and complexity of the SUT grows, the complexity of managing the fixture grows in proportion. This is particularly true as we move from unit tests for simple entity objects (which have simple state models) or utility objects (which are typically stateless) to component tests for stateful service objects or functional tests for entire applications. This set of patterns describes the key techniques for addressing the issues around test fixture management.