User Acceptance testing driven by Humans (with RSpec)
This session was actually two for the price of one. The first part was a presentation about using RSpec and friends for creating user acceptance tests. The slide for that presentation are:
The second part was to answer the question of "What is BDD."
BDD is pretty much just a new name for customer written tests. It differs from TDD because of a change in emphasis and role. TDD emphasizes pushing a design forward by incrementally added requirements and thereby building up a test suite that can tell developers when they have changed some behavior of the system. BDD emphasizes describing the behavior from the standpoint of a user and using those descriptions as tests of a final product. They look very similar and are done very similarly, but have slightly different goals.
NOTE: I (Andrew Parker) am the one who posed the question, so this could all be wrong. This is the impression that I gathered from the session and from my own knowledge.
BDD can be done in any one of several ways (all of these were brought up as different methods used by people in the session):
- DSL: the method presented in the RSpec section of the session. Describe the behavior from the user standpoint in some special language. Interpret that language to test the SUT.
- Hand translate to code: This was done by collecting the behavioral descriptions from users and hand translating them to code that tests that behavior. To keep track of it all the actual text of the description was kept as a comment of the test method. They even had a parser that read the comments to produce wiki pages and documents of what the descriptions in the system were.
- Excel or other table-type system: This was a group using FIT and FITLib for BDD. Good for calculation based (stateless) systems. But not so great for imperative systems (such as moving around on a webpage with a sequence of actions).
