[TIP] Declarative style acceptance tests

Ben Finney ben+python at benfinney.id.au
Mon Jan 6 23:15:01 PST 2014


Michael Foord <fuzzyman at voidspace.org.uk> writes:

> I'm sceptical that any real world customer anywhere, ever (almost),
> actually reads acceptance tests - let alone writes any.

If you'll accept my testimony, I have worked on several successful
commercial projects where the customer got involved in writing the
acceptance test assertions in formal machine-parseable language.

They did so in large part *because* those acceptance test assertions
were actually used as input to our automated test suite, and reports
automatically generated for how many assertions were passing as the
development progressed.

> I'm *very* sceptical that using a poorly specified, undocumented,
> language for writing tests, especially one that *looks* like English
> but is still a formal "programming language" with the strict syntax
> requirements that entails, is any better than just using Python.

We used Cucumber in some cases, and Behave in others; I assume you include
those under your description, though they're deliberately *not* “programming
languages”, because they are declarative, not executable.

They are examples of such formal assertion languages that are much
better than Python code for customer involvement than trying to express
the detailed acceptance criteria.

For whatever my testimony is worth, there are some counter-examples to
allay your skepticism.

-- 
 \       “It is wrong to think that the task of physics is to find out |
  `\         how nature *is*. Physics concerns what we can *say* about |
_o__)                                             nature…” —Niels Bohr |
Ben Finney




More information about the testing-in-python mailing list