From: Joel de Guzman (joel_at_[hidden])
Date: 2006-09-16 20:39:40
Dean Michael Berris wrote:
> Hi Joel!
> On 9/16/06, Joel de Guzman <joel_at_[hidden]> 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
-- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk