One of the most important lessons that I’ve learned as the result of the research conducted Specification by Example is that many of the most common problems people have with implementing BDD or agile acceptance testing come from a misalignment of conceptual models. By changing our view at the specifications/tests we can make most of those issues go away instantly.

The most useful software models are the ones where the technical view of the world is aligned with the relevant business domain model. This ensures that one small change in the business domain (new requirements or changes to existing features) results in one small change in software. This is one of the key ideas of Domain Driven Design. The alignment of the technical and the business models ensures that software evolves nicely with the business and that we never get into a position where a small report change requires a rewrite of the entire system or six months to implement.

The same is true for the other artefacts produced for software — especially tests and documentation. When the conceptual model used in the tests is aligned with the business domain model, one small change in business will result in one small change in tests, making the tests easy to maintain. This applies to the language used in the tests, the abstractions used to describe features and the way that the tests are organised. So I propose the following principle to get good executable specifications/acceptance tests/bdd scenarios/feature files/Fitnesse pages or whatever you call them:

The principle of symmetric change

One small change in a business model should require one small change to executable specifications.

To achieve this, ensure that:

  • each specification should be focused on a single concept of the business domain model (which might be a business rule, step in a flow, or something higher such as the overall definition of a business process)
  • the concepts used in key examples in a specification are closely aligned with the business domain model and reflected in underlying software domain model. this includes naming (concepts are described in the business domain language) but also the relationships between them.
  • the (automated) validation procedure is clearly separated from the specification of key examples
  • the specifications are organised into a living documentation system according to the conceptual relationships that exist in the business domain model

Thinking about aligning key examples and specifications with the business domain model instantly solves many of classic acceptance testing/bdd problems we identified during a CITCON workshop in Paris last year. For example, “Focusing on How, not What” is a sure way to write tests that are very hard to maintain but lots of teams still do it. By thinking about aligning the language and abstraction concepts in the specifications with the business domain model, we force ourselves to describe what the software should do, not how it does it. This separates the specification (what) from the validation procedure (how can we check it in software). The validation procedure can then be automated using a tool. This is a classic problem that Ward Cunningham and Rick Mugridge have identified in Fit For Developing Software nand advised readers not to automate flows. But that is an overly generalised statement - it confuses people who deal with genuine workflows, for example in payment systems where business workflows are everything. David Peterson advised people to focus on specification over scripting, which is less generalised but still not directly to the point. Flows or scripts aren’t the real problem - it is mixing the business definition of a function with the validation procedure.

Thinking about specifications and tests in this way also prevents people from falling into the trap of The Sine of Death by UI Test Automation. Tests described with low level technical detail, in the language of technical UI interactions, are everything but aligned with a business model. If anything, they are aligned with the current design and layout of user interfaces. A small change in business requirements can have a huge impact on such tests, requiring hours of updates to tests after just a few minutes of changes to the code, which then fails the symmetric change principle.

Ensuring that the specifications are aligned with the business model and in the business language, organised according to the relationships the underlying concepts have in the business model solves all the reasons behind the “Tests unusable as live documentation” family of problems, and ensuring that the previous documents are still aligned with the new model resolves most of the issues we described as “Test code not maintained with love”.