Boost logo

Boost :

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-02-02 11:13:57


>>> Yes. What do you get from those macros that's very useful beyond what
>>> BOOST_ASSERT supplies? I really want to know. Some people I'll be
>>> consulting with next week want to know about testing procedures for
>>> C++, and if there's a reason to recommend Boost.Test, I'd like to do
>>> that.
>>
>> So you choose to use BOOST_ASSERT. That essentially means that you
>> couldn't
>> have more than one failure.
> Usually my presumption is that if an assert fails, I can't really have
> confidence in anything thereafter anyway.

So you need to arange statements in your test function in order of
dependency (assuming such order exist). What if class contains some
independent parts.

>> Now believe it or not there exist the whole
>> different testing culture where people starts with *all* of their
>> assertions
>> failing. And then they are working to "fix" them all. And it's not that
>> rare
>> (at best - nowdays TDD is getting widely spread).
>
> Hmm. So you might want to start fixing them without starting from the
> first one?

Sure. It's like a todo list formalized.

>> Another topic is test organization. Boost.Test allows to build complex
>> complex test trees.
>
> Why is that good? At some point doesn't it make sense to write a
> separate test program?

At some point - yes. We just have different opinion where this point. In you
current practice you put all your assertions into single test function. And
them when you collect enough of them split into new file. Nowletw take a
look on a different side of the fence. TDD people put *single* per test
case. Obviosly it means _a lot of_ test cases within the same test module.
And organizing te min test suite (feature-based stage-based or any other
way) is natural next step (Ecpecially if yuou consider suite level
fixtures).

>> In addition it's automate task of testing C++ templates
>> for different set of template parameters of parameterized function with
>> different set of runtime arguments.
>
> Really? I guess there's a lot I haven't seen in the documentation.
> Is there a preview of the new docs somewhere?

This is present for a while. It was reworked completely last release. I do
not want to point you to the unclear docs. Better take a look on
unit_test_example_07.cpp and unit_test_example_11.cpp for reference for now.

>> Latest addition is an ability to test exceptions safety (along the
>> line
>> of the work you did) and facility for logged expectation testing (mostly
>> useful for interaction/boundary testing). There is more to it. If you are
>> really interrested check the docs (well better wait till we update them)
>
> Well, I have checked the docs, and didn't see much of it.

New features are not yet documented.

Gennadiy


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk