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