Acceptance TDD

From CitconWiki
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Acceptance Test Driven Development

Started with 1 word answers to how we feel? Vague, confused, mystified, requirements, Implementation independent.tools??

Slides by Jeremy initially - Works @ Suncorp

  • What is it? How can a team do it? How do developers do their part?
    • Acceptance tests are criteria to get a story over the done line.
    • e.g. Last opportunity that we don't screw up in production
    • Fix requirements
    • Capture requirements
  • When do you right them? Upfront or last?
  • Summary - A lot to do with requirements and what the stakeholders want.
  • What is test driven development
    • Three laws by Uncle Bob
  1. No production code without failing test
  2. Only as much test as to see a failure
  3. No more production code than to make the test part.
  • Adversarial coding. One writing tests, one writing production. Enforces not writing more code than necessary.
  • Story is captured in the story card so we don't lose it. But the acceptance test only has the first part of testing the story then we go and write the code to pass that piece. You don't write the entire acceptance test total.
  • Interesting idea was to have a list of acceptable failing tests. This might encourage TDD.
  • How maintainable are acceptance tests?
    • 1 test - Login -> Do 1 -> Read 1
    • 2 test - Login -> Do 2 -> Read 2
    • What happens when we want to remove Login? All these tests fai. Unit tests get around this by behind smaller and isolated.
  • Customer-defined Acceptance tests are not enough
  • Testers and Developers must define as well
  • Performance testers as well?
  • Customer must understand and accept the Acceptance tests. - Stops developer scope creep for point 3
  • Problem with just customer is that they probably only look at the 'happy' path?
  • Acceptance criteria should cover your functional and non-functional requirements
  • Acceptance tests are the prime interface between Developers and the rest of the team
  • Acceptance test code readable by non-Developers
  • D.R.Y. might have to be put on hold in acceptance tests because abstracting a way can make it hard for customer to read
  • Developers taking responsibility for implementing acceptance tests can leave testers free for exploratory testing
  • What does ATTD actually solve if you were running XP/SCRUM and involving the customer in each iteration and ensuring they are happy after each interation??
  • ATDD doesn't obsolete unit or integration tests but ATDD should drive the initial process.
  • With DBUnit you can feed the result set from one test to be the input to the next test
  • Google search - Business Natural Language
  • Thoughtworks - Twist
  • FIT for confluence? Greenpepper?