What are Executable Specifications or Specifications by Example?

  • Post author:
  • Reading time:3 mins read
You are currently viewing What are Executable Specifications or Specifications by Example?
Use Executable Specification Instead of Long Testing Spreadsheets

Requirements and tests are just two sides of the same coin. You can’t have a user story or requirement without an acceptance criteria (test). These two meld into executable specification.

Using gherkin syntax (given,when,then) we can represent requirements using examples and create specifications by example.

As a potential customer I want to collect books in a shopping cart So that I can order several books at once.
◊ Books can be added to the shopping basket
◊ Books can be removed from the shopping basket
◊ Shopping basket is initially empty
◊ The same book can be added multiple times to the shopping basket

Focusing on the 1st acceptance criteria, we can then write this requirement using specification by example:

As a potential customer I want to collect books in a shopping cart So that I can order several books at once.
◊ Books can be added to the shopping basket
– Given my shopping basket is empty
– When I add the book “Harry Potter” to my shopping basket
– Then my shopping basket should contain 1 copy of “Harry Potter”

The above statement is actually an automated test that run and return a pass or fail result. It is written in a way that a business person can understand and it represent a functional requirement.

If I want to test cart counts or cart content or cart total discounts, I can hook this test directly to where the logic is and avoid exercising all the unnecessary steps to get to the cart.

Many teams use this technique with a tool like selenium which executes these tests via the UI. Again, this is unnecessary for exhaustive functional testing. Selinuim test are long running test and are hard to maintain, so we just need a few of them to make sure everything is connected and works nicely together, but for functional tests, we should run these spec by example tests as close as possible to where the code is.

These specifications by example become “green” documents. Instead of having long spreadsheets of test cases with expected results, actual results and pass/fail, we instead represent our requirements as specifications by example and use them as automated tests. They help the team think and collaborate with the customer, and they communicate what the application really does. They always have to stay current and will not rot. If the requirements change and we update the example, the code will fail so we need to fix the code. If we happen to change the code without updating the example (test), the code will fail and we need to update the example (test). So it ensures our documentation and our code are always in sync.

Also check out the entire Agile Testing series: