Beyond Test Driven Development: Behaviour Driven Development
Why Stack Overflow recommends it
Stack Overflow users link it in lists of TDD/BDD video resources and when discussing top-down, behaviour-first design.
Recommended by 1 people across 1 different months, 2010 to 2011.
What it is
A 2006 Google TechTalk by Dave Astels, author of a Jolt Award winning book on test-driven development, on moving from TDD to behaviour driven development. He explains BDD as a way of specifying behaviour rather than writing tests, drawing on his agile consulting background.
What people said
Recommends Mike Bethany · 2010-11 · Stack Overflow · on “TDD/BDD screencast/video resources”
Here are some videos specifically about Cucumber and RSpec: BDD with Cucumber [LINK] Cucumber: Automating the Requirements Language You Already Speak [LINK] Behaviour Driven Development with RSpec [LINK] Working Outside-in with Cucumber and RSpec [LINK] Beyond Test Driven Development: Behaviour Driven Development [this video] Some general videos about TDD/BDD: Test-Driven Development and Refactoring - Part One [LINK] Test-Driven Development and Refactoring - Part Two [LINK] One of the best free videos on the Ruby Object model (I bought the Pragmatic series on metaprogramming [LINK] after seeing this): The Ruby Object Model - Dave Thomas [LINK] Here are some sites I've gotten some great videos off
Cites Erik Öjebo · 2010-02 · Stack Overflow · on “TDD/BDD screencast/video resources”
Miško Hevery [LINK] , who is a developer at Google, has some great videos [LINK] at his site. Dave Astels has a Google tech talk called "Beyond Test Driven Development: Behaviour Driven Development" [this video] . At Dnr TV [LINK] there are two episodes with JP Boodhoo, where he gives an introduction to test driven development: Test Driven Development with JP Boodhoo, Part 1 [LINK] Test Driven Development with JP Boodhoo, Part 2 [LINK]
Cites luis.espinal · 2011-08 · Stack Overflow · on “Designing APIs in Java with top-down approach - Is writing up the Javadoc the best starting point?”
For an API (and for many types of problems IMO), a top-down approach for problem partitioning and analysis is the way to go. However (and this is just my 2c based on my own personal experience, so take it with a grain of salt), focusing on the Javadoc part of it is a good thing to do, but that is still not sufficient , and cannot reliably be the starting point. In fact, that is very implementation oriented. So what happened to the design, the modeling and reasoning that should take place before that (however brief that might be)? You have to do some sort of modeling to identify the entities (the nouns, roles and verbs) that make up your API. And no matter how "agile" one would like to be, su