---
title: Testing abstrations
url: https://www.grahambrooks.com/post/2009-11-18-testing-abstrations/
date: 2009-11-18T00:00:00+00:00
author: Graham Brooks
tags:
- Agile
- Testing
- Web
---
# Testing abstrations
> These ideas were presented as at href="http://www.thoughtworks.com">ThoughtWorks href="http://connect.thoughtworks.com/agilesoutheast/">Agile
> Southeast conference in Atlanta. The idea for these diagrams
> came about after the first time I spoke about web test driven
> development at href="http://connect.thoughtworks.com/agileeast/">Agile East in
> Philadelphia and New York. I am striving to show how introducing a
> level of abstraction affects development costs.
Web applications should testing at various levels, from unit tests
through acceptance, workflow and performance (to name just a few
categories). For the purposes of this article Acceptance and Workflow
tests are defined as follows:
*Acceptance Tests* - validate the content of the returned document from the application (typically) HTML. Using the test form:
*Given* system in a particular state
*When* a request for a particular resource is made
*Then* the returned document contains these
_Workflow Tests_ simulate how a user is expected to interact with the system to perform the anticipated browser actions.
Both Acceptance and Workflow tests could be executed through the
browser but the Acceptance tests could be run against the application
directly saving the expense of passing data through the
browser. Having the Acceptance tests make direct calls to the
application being significantly faster means that the feedback cycle
is much shorter. Typically there are many more Acceptance style tests
than Workflow tests so keeping the Acceptance tests fast is a
significant benefit.
Having chosen to take advantage of this performance increase it is
likely that the code to exercise the application will be different and
use different technologies.
However, there are significant advantages in maintaining a common
abstraction layer available to both test types.
The chart below expresses the cost of changing an application
correlated against the number of tests supporting development. The red
line represents the cost of change with a minimal or no
abstraction. The blue shows change costs if an abstraction layer is
introduced early in the project.
These charts are not supported by project data but illustrate
experiences on projects. The next chart illustrates that the red (no
abstraction) curve could present a different profile.
What I am pretty sure I have seen on a project is a team stall unable
to proceed because the developing new tests to support new
functionality has hit the exponential part of the curve. Having hit
this wall there are several options but adding a common abstraction
layer to support both Acceptance and Workflow style tests is effective
at unblocking the team. This is illustrated by the chart below.
You might have noticed the small brown dot over the intersections of
the two lines. If it were possible to identify this point either based
on the axes on these charts or some other dimensions then a team could
start with a simple ad-hoc approach and then adopt the time saving
abstractions as they approach the point where the curves intersect. At
the moment not knowing how soon a team would hit this point it would
seem prudent to take the cost earlier than later when the cost of
changing all the tests is significant.