White Box Testing
Test your code
   Home      TestPattern-DataTransactionPatterns
Author -  Marc Clifton
Marc is the creator of two open source projets, MyXaml, a declarative (XML) instantiation engine and the Advanced Unit Testing framework, and Interacx, a commercial n-tier RAD application suite.  Visit his website, www.marcclifton.com, where you will find many of his articles and his blog.
Marc lives in Philmont, NY.

Data Transaction Patterns

Data transaction patterns are a start at embracing the issues of data persistence and communication.  More on this topic is discussed under "Simulation Patterns".  Also, these patterns intentionally omit stress testing, for example, loading on the server.  This will be discussed under "Stress-Test Patterns".

The Simple-Data-I/O Pattern

This is a simple data transaction pattern, doing little more than verifying the read/write functions of the service.  It may be coupled with the Simple-Test-Data pattern so that a set of data can be handed to the service and read back, making the transaction tests a little bit more robust.

The Constraint-Data Pattern

The Constraint-Data pattern adds robustness to the Simple-Data-I/O pattern by testing more aspects of the service and any rules that the service may incorporate.  Constraints typically include:

  • can be null
  • must be unique
  • default value
  • foreign key relationship
  • cascade on update
  • cascade on delete

As the diagram illustrates, these constraints are modeled after those typically found in a database service and are "write" oriented.  This unit test is really oriented in verifying the service implementation itself, whether a DB schema, web service, or other model that uses constraints to improve the integrity of the data.

The Rollback Pattern

The rollback pattern is an adjunct to the other transaction testing patterns.  While unit tests are supposed to be executed without regard to order, this poses a problem when working with a database or other persistent storage service.  One unit test may alter the dataset causing another unit test to inappropriately fail.  Most transactional unit tests should incorporate the ability to rollback the dataset to a known state.  This may also require setting the dataset into a known state at the beginning of the unit test.  For performance reasons, it is probably better to configure the dataset to a known state at the beginning of the test suite rather than in each test and use the service's rollback function to restore that state for each test (assuming the service provides rollback capability).