Boost logo

Boost :

Subject: Re: [boost] Boost.Test updates in trunk: need for (mini) review?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-10-22 15:54:59

Le 22/10/12 02:55, Gennadiy Rozenal a écrit :
> Vicente J. Botet Escriba <vicente.botet <at>> writes:
>> Hi,
>> thanks for taking the time to make this ready for release.
>> I would appreciate if all the new Boost.Test macros start by BOOST_TEST_
> I think the train already left on this one. Plus unlike many other macros which
> you are using here and there testing tools are used quite extensively as part of
> any test module. Making this longer would by an unwelcome change. I do try to
> make BOOST_TEST as a prefix whenever it makes sense. In this case I'd rather
> strive for consise name.
I disagree. Using BOOST_TEST_ as prefix even if longer make the code
clearest. This is one of the Boost rules and any Boost library should
follow them.
>> and you provide the equivalent macros for existing ones that don't
>> follows this pattern.
>> I understand that you want short names, but avoid possible collisions is
>> better than having short names. I could accept also BOOST_TF_ as Boost
>> Test Framework or BOOST_TL_ as Boost Test Library.
> All these abbreviation heart my head a bit. There are bunch of new libraries,
> which even referred to by appbreviation. Sometimes they are fine and if there is
> a concesus that this is the best option, I can live with it, but my preference
> would be something less cryptic.
It is up to you to choose the prefix.
>>> So here we go:
>>> I. New testing tool BOOST_CHECKA
>> I like this a lot. How it works?
> A bit of expression template magic, plus some c++11 for advanced type deduction.
Thanks, this helps me a lot :)
>> What about BOOST_TEST_CHECK (see above)?
> Again this is 2 verbs stuck together. I can live with this, but this is not as
> good as BOOST_CHECK ;o)
Note that in BOOST_TEST_ TEST is not a verb, it is just the name of the
> One option I thought about is to introduce a mode where this new tool is named
> BOOST_CHECK and old BOOST_CHECK is renamed into BOOST_CHECK_...something.
If you decide to change, the library prefix will be best choice ;-)
>>> II. New "data driven test case" subsystem
>>> BOOST_DATA_TEST_CASE( t1, data::xrange(4) ^ strs ^ data::random(),
>>> intval, str, dblval )
>>> {
>>> MyObj obj( dblval, str );
>>> BOOST_CHECKA( == intval );
>>> }
>>> Above test case will be executed 4 times with different values of parameters
>>> intval, str, and dblval.
>> Yes, this will be very useful.
>> Which will be the values for intval? is the index of the tuple?
> The sample tuple is hidden and what you get an an actual argument with specified
> name. So intval is going to be an actual value of type int const&
I see it now, I did understood that data::xrange(4)were a range
generator. BTW, why do you prefix with x?
>> What about adding something like a product test case that will execute
>> the test with the Cartesian product? Is this already available.
> Yes. This is what grid for.
Could I find grid in the documentation?
>>> III. Auto-registered test unit decorators.
>>> Previously is was not possible and/or convenient to assign attributes to the
>>> automatically registered test units. To alleviate this I've introduced a
>>> notion of test unit decorator. These can be "attached" to any test unit
>>> similarly to like it is done in other languages
>> Could you give some references?
> Python for example.
>>> expected_failures - set expected failures for a test unit
>> Could you give an example showing the utility of this decorator?
> This is the same as an existing interface, but applied to auto test case. Yu
> just telling the framework an amount of assertion failures to expect in test
> unit, so these can be "ignored"
My question is why the user wants to check the failures, s/he can just
change the assertion, isn't it? Does the test succeeds if there is less
failures than expected?
>>> description - sets a test unit description
>>> depends_on - sets a test unit dependency
>> What do you mean by depends_on? Is the execution of the test subject to
>> the success of its dependencies or whether the test is enabled/disabled?
> One test unit can depend on another one. For example it makes no sense to test
> access methods if construction test case failed. Thus you might want to have
> introduce dependency of former on to later and if constructio test failed, the
> second test is going to be skipped.
Thanks, now it is clear.
>>> Attachment of decorator is facilitated by using of
>>> that you can use any of '+', '-', '*' symbols to attach decorator
>>> (and any number of '*'):
>> Is there a difference between them? and if not why do you provide all of
>> them?
> Only esthetic. I did not know what users would prefer and there were no problems
> maintaining all of them.
Humm ...
>> Could the following be provided as well?
>> BOOST_CHECKA( foo(a) == 0, "a=" << a );
> BOOST_CHECK_MESSAGE does that already, but you might have a point. I can use
> variadic interface to combine them together. The only thing is that Paul
> insists on treating empty list as non empty one and I'll need to jump through
> some hoops to implement it.
It would be great if you reach to provide it.
>> Wow, you have added a lot of new interesting features. I will check the
>> documentation and start using it as soon as possible.
> I am only starting working on docs for these. Feel free to try and ask any
> questions here meanwhile.

Boost list run by bdawes at, gregod at, cpdaniel at, john at