Long-time readers of Creative Chaos will know that I'm not a big fan of X-drive-Y processes. Sure,
Test-Driven Development was great, but now we've got so many abbreviations poured on top that things are getting a bit silly. (For the record, I think X-driven-Y
jumped the shark at
Bacon Driven Coding, but that's just me talkin')
But, after some time of opposing Behavior Driven Development as a "bunch of nothing'", I have to admit, I do believe I was wrong. Let me explain.
Several years ago, around 2005-2006, I noticed a disturbing trend of super-isolated unit tests that weren't actually testing the return results of functions - they were instead testing what the function was doing. So your function would call int() once and printf() three times - that would be the test. According to the unit testing zealots, actually having real objects, connecting to a real database, etc - well, that was "not a unit test."
I found this resulted in real gains in /design/ of the software, but the regression test suite it produced - not so much. The suite was brittle and not good at catching bugs. I found ways to inject bugs a suite would not catch, or refactor the code so that it worked but the suite would trip an error. (For example, change from three print()s to instead build up a combined string, then just print() once. Code still works, regression test suite registers a 'failure'.)
My colleague, Sean McMillan, and I developed a few cautionary tales on this form of ultra-low-level "testing and presented it at the Google Test Automation Conference in 2007:
Our conclusion? This is interesting stuff, but we wouldn't call it "testing" - perhaps "isolation-based design" would be more accurate.
So this intersects nicely with
Behavior Driven Development, specifically, the falvor of BDD that gave rise to a /behavior/ framework called RSPEC.
You see, under RSpec, you don't call it a test. You talk about the /behavior/ of the software at a low level, replacing words like "test" and "assert" with "should" and "ensure." BDD is about design and doesn't claim to be about testing.
Sound familiar?
So, I think this is huge. Some of the the BDD people took the same observations I did about low-level testing and design and did something positive about it. David Astels, I salute you.
Now, there is a different flavor of BDD, one that is higher-level, where the requirements are expressed as a specification of the form "Given ... When ... Then." If the team has objects with concrete nouns ("The customer", "A membership packet") and verbs ("Requests"), it's relatively easy to automate those tests expressed in near-English.
From what I can tell, the jury is still out on BDD at the customer level. A few people I respect (Including
Chris McMahon) are doing it. I'm cautiously optimistic, in that I suspect the process will have some value, but I'm not exactly sure what.
But, hey, as you can tell from above, I've been wrong before.
So - is anyone here using BDD at the higher levels? What do you think of it? And how long have you been doing it? I'm curious who has used it for more that a couple of years in a row, and what tweaks are required in the process as it gets older.