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

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-02-02 22:08:09

Hi Gennadiy!

On 2/3/07, Gennadiy Rozental <gennadiy.rozental_at_[hidden]> wrote:
>
> "Dean Michael Berris" <mikhailberis_at_[hidden]> wrote in message
> news:6adba9f0702011251m4c852715hb06eb0144c155fd6_at_mail.gmail.com...
> >
> > Interesting, do you have any documentation regarding how to implement
> > extensions?
>
> No I am woring on the docs for this part of Boost.Test.
>

:-) I almost thought you meant "whoring"...

> > Or at least can you lead me on to which parts of
> > Boost.Test I should start looking into? I already have Boost CVS HEAD
> > at the moment...
>
> Take a look on:
>
> boost/test/
> exception_safety.hpp
> interaction_based.hpp
> logged_expectations.hpp
> mock_object.hpp
>
> boost/test/impl/
> exception_safety.ipp
> interaction_based.ipp
> logged_expectations.ipp
>
> libs/test/example
>
> est_example1.cpp
> est_example2.cpp
> logged_exp_example.cpp
>

Great, thanks! I'll go on and take a look for myself. :-)

> >> How does it correspond to what you are trying to do? Do you see any
> >> intersections and or possible additions to what Boost.Test currently
> >> presents.
> >>
> >
> > I guess it would be better to show an example of what the BDD
> > interface is about:
> >
> > std::string str = "Hello, World!";
> > value(str).should.equal("Hello, World!");
> >
> > I had been thinking that the implementation of
> > `value(str).should.equal(...)' should use something like
> > BOOST_CHECK_EQUAL(str, ...).
>
> Sorry. I do not see your point. Why can't you write:
>
> BOOST_CHECK_EQUAL(str, "Hello, World!")
>

This is all fine and dandy if you're used to writing assertions.
However, the BDD interface (current latest version under development)
also allows you to do:

    value(str).should.match("regex pattern");

This little line can be used within a function to validate input, and
not necessarily have to be in a Unit Test:

    int some_function(std::string const & str) {
        #ifdef DEBUG
            value(str).should.match("regex pattern");
        #endif
    };

It should also be trivial to create a wrapping macro to do the
preprocessor checking for debug version builds, and appropriate
exception handling routines.

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.

> Maybe after reading code and/or examples you could give me some comparison
> of what I have and what you want to do. Be aware that I may not be familiar
> with some of the term you are using.

I already currently use (quite extensively) Boost.Test and the
BOOST_REQUIRE/BOOST_CHECK macros in BOOST_AUTO_TEST_CASE blocks. I've
also been successful in using the BDD interface in these unit tests,
in a manner such as:

  BOOST_AUTO_TEST_CASE ( some_test ) {
    int result = perform_some_operation("Hello, World!");
    value(result).should.be_divisible_by(3);
  };

as compared to

  BOOST_AUTO_TEST_CASE ( some_test ) {
    int result = perform_some_operation("Hello, World!");
    BOOST_REQUIRE_EQUAL ( true, ((result % 3) == 0) );
  };

HTH!

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