A MYSTERY SHOPPER wrote:


But here is the part I can't stand about Acceptance Test Driven Design.

When I first started we had two automation engineers, me and this other person. The other automator quickly fell behind. She would start making these stupid test cases in Fitnesse that ended up having nothing to do with how the app actually exported data. So she would throw all that away and start over when the feature was actually finished. I looked at this as a complete waste of time. She could have been doing a million other things that would be useful in the time she took to make those stupid pages in the name of test-driven design.

They are really banging that drum. A test before the feature is done. It's stupid to me. You know what, you can maybe do it if you are tweaking behavior in something that already exists. "A non-admin user can do a certain thing, write a test that will "pass" when they can no longer do that thing." Sure. But it never works for totally new things. I think the entire concept of taking people who are busy at work and making them do work that is thrown away and THEN the real test is wasteful. Plus, nobody documents anything and we don't have specs. I hope that things are more sane where you are.

1. A biz type, a dev, and a tester get together and define acceptance criteria for a card


2. The dev and the tester go off to their office...
   
   • The tester starts fleshing out the acceptance tests with additional edge cases and wires up the existing steps, adding additional ones where possible
   
   
   • The dev writes the new production code
   
   
3. The dev and tester collaborate to fill in new steps that didn't exist before the feature started


4. The feature is demo'd, everybody does some exploratory testing, and then the feature is merged with production

• BDD is a suped-up TDD where the unit and integration tests are business-readable. It's test-first.


• ATDD is a methodology that gets agreement on scope and functionality before cards are started in the form of acceptance criteria, and demonstrates that cards are done via automating those acceptance criteria. It's not test-first because the only reason TDD or BDD can work is that the tests and the AUT are being written at the same time by the same person (or pair).