Unit Test Design Patterns

Process Patterns

Unit testing is intended to test, well, units...the basic functions of the application. It can be argued that testing processes should be relegated to the acceptance test procedures, however I don't buy into this argument. A process is just a different type of unit. Testing processes with a unit tester provide the same advantages as other unit testing--it documents the way the process is intended to work and the unit tester can aid the implementer by also testing the process out of sequence, rapidly identifying potential user interface issues as well. The term "process" also includes state transitions and business rules, both of which must be validated.

The Process-Sequence Pattern



This pattern verifies the expected behavior when the code is performed in sequence, and it validates that problems when code is executed out of sequence are properly trapped. The Process-Sequence pattern also applies to the Data-Transaction pattern--rather than forcing a rollback, resetting the dataset, or loading in a completely new dataset, a process can build on the work of the previous step, improving performance and maintainability of the unit test structure.

The Process-State Pattern



The concept of state cannot be decoupled from that of process. The whole point of managing state is so that the process can transition smoothly from one state to another, performing any desired activity. Especially in "stateless" systems such as web applications, the concept of state (as in the state of the session) is important to test. To accomplish this without a complicated client-server setup and manual actions requires a unit tester that can understand states and allowable transitions and possibly also work with mock objects to simulate complicated client-server environments.

The Process-Rule Pattern



This test is similar to the Code-Path pattern--the intention is to verify each business rule in the system. To implement such a test, business rules really need to be properly decoupled from surrounding code--they cannot be embedded in the presentation or data access layers. As I state elsewhere, this is simply good coding, but I'm constantly amazed at how much code I come across that violates these simple guidelines, resulting in code that is very difficult to test in discrete units. Note that here is another benefit of unit testing--it enforces a high level of modularity and decoupling.
 
source: Marc Clifton - http://www.codeproject.com/KB/architecture/autp5.aspx