We specify examples and automate the specification as business-facing tests. It may be instuctive to step through an example to illustrate. We've decided we want to build a feature. A basic picture which I can alter on screen via a set of controls. Lets go ahead and specify behaviours we want to see.

artboard11 1

An Example

  • I want to place a small picture on a web page. A picture based on rectangles
  • I want to be able to show and hide our picture
  • I'd like to see and hide the lines within the frame
  • Be great if i could turn colours in the picture on and off independently
  • Finally, i want to rotate the whole picture
next-arrow-svgrepo-com 1

We hope this illustrates that this Conversations -> Examples -> Tests thing is a natural process. Anybody interested in how the software can and should contribute.

Testclub will take these examples and formalise them into acceptance tests. These tests then play the multiple roles of acting as Active Specification AND Automated Acceptance Tests AND Living Documentation

So, developers get the spec and the feature is built (have a play yourself!)

Here are some running. Ideally your CI environment will kick them them off just as for your unit tests:


So this passes the functional contracts we wrote and agreed. Great!

To state the obvious though - these tests are just a machine performing a series of automated checks

What's not immediately obvious is that the most valuable actions performed here in terms of risk mitigation were the upfront efforts in forming a behavioural specification. A process which drove out many functional gaps before any code was written

We're technology agnostic, meaning we are multiskilled and will write automated tests with the best tool for the job within the specific context of your project