Hi Gennadiy! On 2/2/07, Gennadiy Rozental <gennadiy.rozental@thomson.com> wrote:

"Dean Michael Berris" <mikhailberis@gmail.com> wrote in message news:45C2358E.3090807@gmail.com...

...

That being said, that discussion is a good 4 months ago, and would like to ask the following questions to those who might be interested in something like this:

* What degree of integration with Boost.Test be "suitable"? Though I see Boost.Test has a wealth of preprocessor macro's going about, it shouldn't be hard to integrate at that level.

I do not have time at the moment to look though your code. But just as a n information:

Starting Boost1.34 Boost.Test includes "Interaction based testing" support. The support is presented as a framework for different extensions. The two "extensions" implemented already within the Boost.Test is "Logged expectation testing" and "Exception safety testing". If you are interested they are in cvs HEAD and RC.

Interesting, do you have any documentation regarding how to implement extensions? 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...

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, ...). The idea really of the BDD interface is to provide an alternative which is closer to English for specifying behavior. I'm looking to have this interface available with or without Boost.Test, in which case the library can be used even in debug builds, as such: void some_function (int some_value) { // validate some_value // and should only be relevant in debug builds boost::spec::value(some_value).should.be_greater_than(1); // do whatever some_function should do }; Currently the usage scenario with Boost.Test would be the following example: BOOST_AUTO_TEST_CASE ( some_test ) { int an_int = 0; BOOST_REQUIRE_NO_THROW( value(an_int).should.not_equal(0) ); }; Which I admit, is not pretty at all. Would appreciate further input. Thanks! -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459

Hi Gennadiy! On 2/3/07, Gennadiy Rozental <gennadiy.rozental@thomson.com> wrote:

"Dean Michael Berris" <mikhailberis@gmail.com> wrote in message news:6adba9f0702011251m4c852715hb06eb0144c155fd6@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 +63 928 7291459

On 2/3/07, Sohail Somani <s.somani@fincad.com> wrote:

I'm not sure I see the value in that vs:

BOOST_REQUIRE_IS_DIVISIBLE_BY(result,3)

I must be missing something

The question with the above interface is that "which one are you requiring to be divisible by what?" which is not always obvious. Saying that "this value should be divisible by three" is translated (almost) directly as value(result).should.be_divisible_by(3); At least that's how I see it. HTH! -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459

On 2/4/07, Gennadiy Rozental <gennadiy.rozental@thomson.com> wrote:

"Dean Michael Berris" <mikhailberis@gmail.com> wrote in message news:6adba9f0702021908t2cf6fcf5ia3d7a92229294faa@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 +63 928 7291459