Please log in to watch this conference skillscast.
BDD started as a way to teach TDD to programmers who kept getting hung up on the idea they were writing tests. Fast-forward a decade or so and it seems BDD scenario automation tools have invaded the world of acceptance testing like Japanese knotweed. All around I see teams harming themselves writing awkward, verbose tests using slow, cumbersome tools like Cucumber and SpecFlow, and acting as though BDD is some kind of testing approach.
Part of the problem is that once you have an automated BDD scenario and you've written the software to satisfy it, it can look seductively like a test. From there it is a short step to thinking of these scenario automation tools as testing software, and the rest is frustrating, repetitive history.
This long-overdue talk explores the relationship between BDD scenarios and acceptance tests, and suggests some strategies for avoiding the pain of BDD-as-test automation.
The Call for Papers is now open for Agile Testing & BDD 2017! Submit your talk for the chance to join a stellar line-up of experts on stage. Find out more.
YOU MAY ALSO LIKE:
BDD is not about Testing
Dan North uses his deep technical and organisational knowledge to help CIOs, business and software teams to deliver quickly and successfully. He puts people first and finds simple, pragmatic solutions to business and technical problems, often using lean and agile techniques. With over thirty years of experience in IT, Dan is a frequent speaker at technology and business conferences worldwide.