Re: [boost] Interest in a Behavior Driven Development Framework

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2006-09-14 11:05:41

Hi Dave!

On 9/14/06, David Abrahams <dave_at_[hidden]> wrote:
> "Dean Michael Berris" <mikhailberis_at_[hidden]> writes:
> > It's really just a "clarification" of Test Driven Development. The
> > gist is as follows:
> >
> > * Instead of emphasizing on "Tests", you emphasize "Specification".
> >
> > * The assert_* line of methods leans on the "testing" and
> > "invalidation" of results and values.
>
> Yeah, I heard him say that, but didn't buy that line at all.  An
> ASSERT says: here's what I'm saying the behavior/result is.  That's
> specification.
>

When you get used to ASSERT_SOMETHING(value, expected), you run into
"testing mode" because that's what ASSERTs read like. There's nothing
inherently wrong with specifying behaviour by asserting that a state
be true (or not true) after a set of operations -- it just doesn't
"read as well as" something like
`value(value).should.equal(expected)'.

> >
> > * Specifications are made more readable. They have an implementation
> > in Ruby called `RSpec' which uses a more readable framework than
> > `assert_something(value_tested, expected_value)' -- you can look at
> > http://rspec.rubyforge.org/ for more information on that.
>
> Yeah, OK, so there's a DSL... not a very convincing one either,
> especially in light of the use of "should"
>

The idea with the use of 'should' is mainly for readability in lieu of asserts.

Additionally, you can even introduce something like "can" used in this context:

type<my_type>::can::serialize;
type<my_type>::can::index_<int>;
type<my_type>::can::be_a_functor< int (int, int) >;
type<my_type>::can::not_be_derived_from<parent_type>;

For static behavioral specification/testing.

So now you can generate your test suite that can read like:

//...
type<my_type>::can::serialize;

my_type my_first_instance, my_next_instance;
my_first_instance.set_value(1);
//... deserialize
ar >> my_next_instance;

value(my_next_instance.get_value()).should.equal(1);

> > It's not different from TDD, but it's a clarification of it.
>
> Somehow it was much less clear to me, because it was sold as some kind
> of revolution.
>

I don't think I also caught on to the "revolution", but I really liked
how the code read like with "should" instead of "assert". :-)

> > It still follows the same concepts, only the tools are made closer
> > to read like you're actually specifying behavior instead of
> > invalidating state with asserts.
>
> You mean validating, don't you?
>

Yes, I meant validating. :-)

> And the distinction between state and behavior is extremely weak, at
> least as presented so far.
>

Indeed, but the idea of being able to specify with more readable
(english) language allows you to think in specification mode, thus the
distinction of state and bahvaior can be made egligible. [I don't
think that last statement made a lot of sense, but I wrote it
anyway... ;-) ]

-- 
Dean Michael C. Berris
C++ Software Architect
Orange and Bronze Software Labs, Ltd. Co.
web: http://software.orangeandbronze.com/
email: dean_at_[hidden]
mobile: [phone]
phone: [phone]
other: [phone]
blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com
http://cplusplus-soup.blogspot.com