Unit Test Design Patterns
Data Driven Test PatternsConstructing Parameter-Range unit tests is doable for certain kinds of testing, but it becomes inefficient and complicated to test at a piece of code with a complex set of permutations generated by the unit test itself. The data driven test patterns reduce this complexity by separating the test data from the test. The test data can now be generated (which in itself might be a time consuming task) and modified independent of the test.
In the simplest case, a set of test data is iterated through to test the code and a straightforward result (either pass or fail) is expected. Computing the result can be done in the unit test itself or can be supplied with the data set. Variances in the result are not permitted. Examples of this kind of of Simple-Test-Data pattern include checksum calculations, mathematical algorithms, and simple business math calculations. More complex examples include encryption algorithms and lossless encoding or compression algorithms.
The Data-Transformation-Test pattern works with data in which a qualitative measure of the result must be performed. This is typically applied to transformation algorithms such as lossy compression. In this case, for example, the unit test might want to measure the performance of the algorithm with regard to the compression rate vs. the data loss. The unit test may also need to verify that the data can be translated back into something that resembles the input data within some tolerance. There are other applications for this kind of unit test--a rounding algorithm that favors the merchant rather than the customer is a simple example. Another example is precision. Precision occurs frequently in business--the calculation of taxes, interesting, percentages, etc., all of which ultimately must be rounded to the penny or dollar but can have dramatic effects on the resulting value if precision is not managed correctly throughout the calculation.
source: Marc Clifton - http://www.codeproject.com/KB/architecture/autp5.aspx