Re: [boost] [Release 1.34] Supported Compilers - another view

From: David Abrahams (dave_at_[hidden])
Date: 2006-02-02 12:25:42

"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:

>>>> 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.

Normally I use separate test programs to test independent things.
That admittedly does run into a lot of compilation time.  However, so
often there's a chance of one small piece failing compilation on a
given compiler, and in that case I still want to know the rest is
working.

>>>    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. 

No, I usually split into a new file each time I'm testing a new aspect
of the system.

> 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.

I'll try to have a look.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com