There are slides to talk along with. This is really about introducing some of the ideas around ATDD. In particular:
- Introduction acceptance testing as the "outer cycle" to the red-green-refactor/TDD cycle.
- De-coupling executable fixtures from "specifications"
- Abstracting the meaning of "done" out of the specifications and into fixture and test code (insulating the specifications)
- A bit of background on Concordion and the basic mechanics (there's an example of an acceptance already in the code base to refer students too)
During the practical element of the session make sure you have enough helpers to act as "customers", fielding questions and clarifying the previous transcript. If you can, make sure the customer gives differing advice to the group. For example, either don't explain what address should be shown on the statement or claim it should be the customers and the branches (to differing people).
As an alternative, it seems to work well doing a group exercise. This can be in the form of getting the audience to shout of what they think are the requirements and listing them on a flip chart. When they're all collected, point out that these are all assumptions. Ask how we could validate these assumptions?
The instructor branch https://github.com/xp-dojo/atdd-bank-account/tree/instructors contains a reference implementation which you can demo as and when.
It's important to show a finished example at the end of the session.
You should show a worked example at difference stages to:
- Show how a partial acceptance test (lets say without interest accrued or even just deposits and not withdrawals)
- How that partial acceptance test iterated (the acceptance criteria evolved)
The learning point here is about not taking on too much and instead breaking the ATDD loop into smaller iterative loops, each concluding with a customer demo and improved understanding of the requirements. Remind people about the difference between iterative and incremental. Remind people that they should be speaking to actual humans during this process.
Who put the address on the statement? Was it the customer address? or the branch address? Both? Who asked for that? How did you clarify your understanding?
Make sure you describe the steps: 1) write a failing acceptance test, 2) go straight into the TDD loop until 3) the acceptance test passes.
In Concodrion, you can use @Unimplemented or @ExpectedToFail annotations which going round the loop.
Make sure you talk about how pushing assertions into fixture and test code insulates the specification from change (giving a test code base that grows with the application) and moves towards a more BDD approach.
Use the payment slip example (with echoed output vs a string comparison in the HTML layer). Talk about how this only comes about when you've earned trust with the customer so they're confident that a "green" block of test has actual meaning and value.