Re: [boost] Re: Re: [Test] BOOST_TEST removed?

From: Martin Wille (mw8329_at_[hidden])
Date: 2005-02-03 08:27:11

Gennadiy Rozental wrote:
> "Martin Wille" wrote in message
> news:4201D178.60406_at_yahoo.com.au...

>>Well, one thing that is wrong with red squares is that they
>>cost resources.
> 
> 
> Sure. Testing cost resources. But it brings real value instead. In this
> case, for example, it served as a change announcement. It general it brings
> a level of confidence so you could make any changes. If anything breakes
> test system tells you so. In extreme TDD you start with all test cases
> failing (some of them written even before implementation is done) and then
> fix them.

Tests are never the right medium for a change announcement.
Your "change announcement" costs hours of CPU time here.

A simple grep would have been sufficient to find all
places where the BOOST_TEST macro is still in use and
it would have taken only a few minutes.

>>Testing time significantly grows with the
>>number of failing tests.
> 
> 
> Why is that? You need to redo any test case affected in any case, right? So
> test failing in compile time, for example, may actually decrease testing
> time (no linking, no running)

Yes. It's just that the compile time is significantly larger
than linktime + runtime.
Also, stuff that has been tested successfully won't be
retested unless there is a change.

>>Giving the developers a chance to
>>phase out BOOST_TEST would have decreased the number of
>>attempts to compile broken code.
> 
> 
> It's kinda unclear what change needs to be pre-anounced and which not. Any
> anouncement assumes some grace period (and what if some developers are
> unavailable or missed an anouncement?). It also assumes that something
> should be done before the change will actually happend. It all eventually
> leads to longer development time for one who make an anouncement. Amount of
> time/work for the rest of developers is the same (I would guess that it even
> less with known test cases that needs to be fixed and change already in
> place). In any case I do not see a failing test case as a something to be
> upset about. Rather I feel satisfaction that testing system again helped me.
> It much worse when all test cases are passing and you finding error only in
> users reports. This makes tests a most valuable and salvagable part of any
> project (IMO)

Right, there's no clear rule when to pre-announce and when not to.
In that situation, it often is useful to make an educated guess
about the possible consequences of a change before committing
it. Simply searching for BOOST_TEST in the sources would have
identified all relevant places in the code. If the number of
those place is high then the consquences are presumably large
and an announcement would be helpful.

[...]
> 
> P.S. Above sentiments of course assumes that all the developers making
> changes actually to improve the project, not to break one ;)

Sure. I don't think anyone here would change anything
willingly in a way that is not an improvement somehow.
Gee, I hope you didn't misunderstand me. I never accused
anyone of deliberately breaking stuff without good reason.

Regards,
m

PS: grepping for BOOST_TEST[^_A-Z] in boost/libs yields
     4637 hits, one of them in depecated.html and one in
     a comment.