The Ambient object is like a persistent whiteboard used to pass information from one test to another or to store it for subsequent analysis.

The Ambient object store may be used to model the persistent state of the testing environment for end-to-end black-box integration testing. It is particularly useful for decoupling tests that incorporate stateful components such as databases (that are not wiped and restored each time) or time-sensitive processes such as asynchronous jobs.

Suppose we are testing a periodic invoicing process. The business requirement dictates that on the last day of each month, an invoice must be generated and delivered electronically to all customers with an outstanding balance in their account.

To verify this requirement, we might choose to adopt a combination of unit testing and integration testing methodologies.

First, we will write unit tests for each component involved in the invoicing process including the invoice generator, data access code, electronic delivery apparatus, and the periodic job scheduler. During unit testing, we will probably replace the periodic job scheduler with a mock or stub implementation that simulates the end-of-month trigger mechanism. This is fast and quite effective.

Next, for additional confidence we will want to verify that the system works completely as an integrated whole. Perhaps the job scheduling mechanism is built on 3rd party tools that must be correctly configured for the environment. In this situation, we might consider implementing an end-to-end system test with nothing mocked out.

We can implement an end-to-end test like this:

• Write a few test scripts that are scheduled to run on a regular basis and that generate transactions that will be reflected in the invoices.
• For each transaction, such as creating a new account or purchasing a service, the scripts should make a record in the Ambient object store.
• Write a few more test scripts that are scheduled to run after the invoicing process occurs. They should verify the contents of the invoices based on previously stored records in the Ambient object store.

Of course, in this example it can take up to a month to obtain confirmation that the invoicing process functioned as expected. Consequently, we should not rely on this approach exclusively for our testing purposes. Nevertheless, it may be useful as part of an on-going Quality Assurance audit.