Dean Michael Berris wrote:
Hi Joel!
On 9/16/06, Joel de Guzman <joel@boost-consulting.com> wrote:
The question is how BDD can help write code that clearly reflects the algorithms involved. Try the simple for_each, see if you can convince me. Then try a more elaborate algorithm, say, quicksort. See if you can capture the essence of the algorithm in BDD.
I think there's a blurring between the use of documentation and specification here. Let me try to clarify a few things as to what BDD wants to be able to achieve:
* Write Specification Suites for validating program behaviour :: In lieu of calling these specification suites "test suites".
* Allow for writing programmatic specifications for systems, subsystems, components, and "units" :: in liew of calling them system level tests, integration tests, and unit tests
BDD does not aim to remove external documentation, but it does aim to make the specification process programmatically consistent with natural language.
Instead of "Unit Testing" you have "Behavior Specification". Contrasting `ASSERT_EQUAL(_expected, _value)' with `value(_value).should.equal(_expected)'. It's really just that simple. ;-)
Fair enough. Perhaps I was just taken aback by the hype. I find it alarming whenever I read things like "the next big thing", a "revolution", etc. Reminds me a lot about Java. (sorry, can't resist). Anyway, I should assert (pardon the pun ;) ) that behavior specification in code (as a DSEL?) is an illusion. People would tend to believe that with it, you can specify a program behavior and get away with no documentation. Proof in point: Richard Newman's post (unless I misunderstood him). That makes me worry. Regrards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net