Re: [boost] Interest in Behavior Driven Development Interface(again)

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-02-04 13:14:33

On 2/4/07, Gennadiy Rozental <gennadiy.rozental_at_[hidden]> wrote:
>
> "Dean Michael Berris" <mikhailberis_at_[hidden]> wrote in message
> news:6adba9f0702021908t2cf6fcf5ia3d7a92229294faa_at_mail.gmail.com...
> > So the real answer to the question is that nothing actually stops you
> > from using the BOOST_CHECK or BOOST_REQUIRE macros in Boost.Test --
> > I'm just looking to provide an alternative interface to defining
> > specifications not only in Unit Tests, but also in different parts of
> > the code. The goal really of the interface is for a novel "more
> > English like" way of defining specifications, where it is explicit
> > what the value being inspected is and what the expected behavior is.
>
> So I understand you want to write a framework for men friendly runtime
> specification enorsement interfaces with configurable check and/or report
> agent.

That's a good way of putting it.

And the "want" is already being addressed -- I've put up some code
already released under the Boost Software License. :-)

> This has almost nothing to do "Interaction based testing". Later is intended
> to test that for a given input particular interaction occurs (vs. "state
> based testing" that for given input validates that result match expected
> value).
>

I don't think I see yet how "interaction based testing" is defined,
and would love to be enlightened (I have done mock object testing
before, which is still pretty much in the end "state based" anyway,
AFAICT).

> One word of caution. The target audience for your framework are developers.
> And developers tend to be lazy and unwilling to learn anything new. There
> should be real advantage for developer to decide to write
>
> value(arg).should.be_divisible_by(3);
>
> instead of usual and always available
>
> assert( arg%3 = 0 );
>

Thanks, it's a warning I very much take into consideration. And there
has been a lot of gotcha's with assert(...) where the usual mistakes
are "inadvertent state modification" -- take the assert(value = 20)
where the intended idea is assert(value == 20). Compare this to the
non-modifying "value(value).should.equal(20)" where it's more
explicitly defined/specified that "value should equal 20".

Of course, old habits die hard and whatever works would be fine -- but
that doesn't mean we should stop from introducing ideas and
alternatives which may have merit if not immediately but in the long
run.

Thanks for taking the time! :)

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
[phone]