Test-driven development is a programming practice that produces well-designed code and leaves behind unit tests that are critical to refactoring with confidence. But TDD is not a testing technique, it is a design technique that happens to leave unit tests in its wake. In this talk, we'll use examples to discover some of the ways TDD fails to provide value and fill those gaps by incorporating acceptance tests, specification by example, and behavior-driven development. We will consider our test suite the result of a value chain where user stories start in design, make a smooth transition to executable acceptance tests, are engineered with BDD and TDD, and end as living product documentation. The result will be tests that clearly reflect both behavior and their value while increasing the happiness of everyone involved in the process.
My goal for this talk is to leave you with examples and techniques for:
- developing and refining user stories
- determining when a user story is ready to become a feature
- ensuring that domain knowledge developed in design is never lost
- ensuring that developer productivity only increases with behavior-driven development
- writing clear and concise acceptance tests with measurable value and minimal brittleness
The patterns and practices presented are largely language and framework-agnostic. Code examples are given in multiple Ruby testing frameworks.
I am a Rails Engineer at MeYou Health in Boston's South End where science and social networks help people maintain more healthful lives. I've been a Ruby developer for seven years. I hope to bring a new perspective on acceptance testing, demonstrate its value in concrete ways with real code (and hilarious memes), and share reproducible patterns and techniques for avoiding common pitfalls that can turn people away from BDD. This talk has been given but not in a conference setting.