Have been doing a lot of reading, playing, studying, experimenting around aligning specification and software recently.
(Some background: I recently accepted a new position running Engineering @ PlaceIQ – and so have a clean slate in a hyper-growth environment to think about the classic problem of “ahhh…. our users give us terrible requirements” – of course they do, they’re not trained/practiced in requirements analysis…)
BDD is something that on/off I’ve been watching/trying the last couple of years. TDD changed my life (as it may have changed yours) – but while it did a great job confirming “I built what I thought I should build”, it did a less great job confirming “I built what was needed to be built”.
(Another note: I distinguish “I built what was needed to be built” from “I built what I was asked to build”)
BDD though I think adds a critical layer of translation/transparency – it gives us a common check-point to agree on and review the *key* behaviors of the system – and provides a language in Given-When-Then that structures how we think about it’s behavior. https://sites.google.com/site/unclebobconsultingllc/the-truth-about-bdd I think has an awesome post where he sums up that:
Some of the brightest minds in our industry, people like Dan North, Dave Astels, David Chelimsky, Aslak Hellesoy, and a host of others, have been pursuing the notion that if we use a better language to describe automated requirements, we will improve the way we think about those requirements, and therefore write better requirements. The better language that they have chosen and used for the last several years uses the Given/When/Then form which, as we have seen, is a description of a finite state machine. And so it all comes back to Turing. It all comes back to marks on a tape. We’ve decided that the best way to describe the requirements of a system is to describe it as a turing machine.
Cucumber has been the latest tool I’ve been playing with to try to see where this takes us – and on the whole… I like where it’s going. https://github.com/cucumber/cucumber/wiki/Given-When-Then is something I think I can take to my business users (we’ll see 😉 ) and the harnesses let me hook into Maven and all my other tooling to then confirm that we’ve done X,Y,Z – and tie in regression results so they key in too. Also – creating a specification library gives me the other piece that I’ve always felt was missing in terms of issue-tracking – tracking the current-state of the system vs. just deltas.
Exciting enough to work on on a Sunday afternoon, anyway…
BDD as Finite-State-Machine (FSM)
Have been doing a lot of reading, playing, studying, experimenting around aligning specification and software recently.
(Some background: I recently accepted a new position running Engineering @ PlaceIQ – and so have a clean slate in a hyper-growth environment to think about the classic problem of “ahhh…. our users give us terrible requirements” – of course they do, they’re not trained/practiced in requirements analysis…)
BDD is something that on/off I’ve been watching/trying the last couple of years. TDD changed my life (as it may have changed yours) – but while it did a great job confirming “I built what I thought I should build”, it did a less great job confirming “I built what was needed to be built”.
(Another note: I distinguish “I built what was needed to be built” from “I built what I was asked to build”)
BDD though I think adds a critical layer of translation/transparency – it gives us a common check-point to agree on and review the *key* behaviors of the system – and provides a language in Given-When-Then that structures how we think about it’s behavior. https://sites.google.com/site/unclebobconsultingllc/the-truth-about-bdd I think has an awesome post where he sums up that:
Cucumber has been the latest tool I’ve been playing with to try to see where this takes us – and on the whole… I like where it’s going. https://github.com/cucumber/cucumber/wiki/Given-When-Then is something I think I can take to my business users (we’ll see 😉 ) and the harnesses let me hook into Maven and all my other tooling to then confirm that we’ve done X,Y,Z – and tie in regression results so they key in too. Also – creating a specification library gives me the other piece that I’ve always felt was missing in terms of issue-tracking – tracking the current-state of the system vs. just deltas.
Exciting enough to work on on a Sunday afternoon, anyway…