Re: [boost] Boost.Test - misc observations

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-06-13 13:12:55

Gennadiy Rozental wrote:
> "Robert Ramey" <ramey_at_[hidden]> wrote in message
> news:e6etq0$7he$1_at_sea.gmane.org...
>> Dear Gennadiy Rozental,
>
> Hmm, no "sir" - well for the fellow booster plain Gennadiy should
> work ;o)

aaaa - unfortunately I can't figure out how to pronounce this so I can't 
remember how it's spelled.  I didn't want to say "Mr. Rosenthal" given that 
we're on such intimate terms, so I just copied your full name.  OTOH I spent 
many years outside the U.S. after being living in Califonia until my 
twenties.  When I came back to the U.S (now twenty years ago) is was struck 
by the "instant familiarity" of american language and customs.  It stll 
seems odd to me to hear - "My name is Brittany - I'll be your waiter this 
evening.  The first time time this happened, I stood up shook her hand, 
introduced my wife (she's from germany) and said "Hello, My name is Robert 
and this is my wife Annegret and we'll be your customers".  Unfortunately, 
this provoked consturnation among the staff rather the the hilarity I had 
anticipated. It wasn't totally lost - my wife thought it was hysterically 
funny.  No real point here - I'm still hoping to find someone who can laugh 
at my humor.

> Hi, Robert
>
> If you care for my opinion, it would not be a wise move, unless you
> don't case about the quality of your tests of course. Current state
> of the Unit Test Framework (UTF) allows me to state that it's a
> preferred solution in all possible use scenarios (simplest one-liner, 
> simple single
> function test with several assertions or complex multilevel test case
> structure) from all possible angles:
>
> * usability
> * functionality
> * compilation time

Hmmm - and universality?

> We discussed this couple time and I thought I was clear.
> Ok. Lets imagine two years from now boost decides to drop msvc 6.5
> from regression testing.

>From my personal perspective, it could be dropped right now as I happen to 
test that on my own machine whenever I make a change.  Same goes for BCB 
5.51 and 5.64

> Would you still insist on maintaining this
> configuration? Even though none of the boost components you depend on
> are going to be tested on it and accordingly will start to fail
> sooner or later?

> My hope is that your answer is no. In this case I
> could most solemnly swear that Boost.Test will work on all platforms
> boost perform regression testing on and you have nothing to worry
> about.

***
Hmmm maybe this is the crux of the difference.  I don't see Boost Test as 
primarily a means running boost regression testing.  Of course its that, but 
I see it as much more.  I see it as the "Tool of choice" for users making 
C++ unit tests.  which is not quite the same thing.  The boost regression 
testing environment is sort of special - it presupposes installation of bjam 
and building boost libraries etc.  This is more of a "marketing" view point. 
Some boost libraries benefit by being almost universal - others not.  Boost 
Test is one of the former.

***
So, I have a different take on this.

Suppose I make library A.  As library author I can decide which platforms 
(in addition to the mythical totally conforming compiler and standard 
library) it will run on.  This isn't a decision made by boost or boost 
policy.  And of course its going to vary by library.  BOOST_STATIC_ASSERT 
can and should be made almost universal.  Boost Lambda cannot be without 
crippling its usefulness.

So library B is implemented and running nicely on the platforms the author 
has decided its appropropriate to support.  Library B depends upon Library 
A.   Library C comes along and doesn't support all the platforms that 
Library B does - but that's no problem as Library A doesn't depend on B. 
The author of Library A adds some new functionality.  Still no problem since 
he left in the old code.  Now Library A makes some changes which break the 
original API for some platforms.  Of course that is where the problem 
arises.  But why is it necessary for the author of Library A to do this? 
What does it cost him to just leave to original code in?  The code is 
already written and tested.  As an example, the serialization library still 
works with BCB 5.51 and VC 6.x.  Its not that I invest any effort to do 
this - Its just that it costs me nothing to leave this facility available. 
A good example is spirit.  Spirit has moved on but left sprite 1.6x around - 
this solution has worked well for me.

>> I've had problems testing the serialization library with comeau
>> compilers because both the serialization library and boost test
>> include instantiated code for string output and the comeau
>> "pre-linker" fails here.

>> Change # 1

>> A small change to permit commeau to be tested with the serialization
>> library.  This is obviously a crude hack but perhaps it can be fine
>> tuned to make it acceptable.

This addresses the comeau pre-linker issue.  Perhaps the fact that this 
"solves" the issue for the serialization library might give you a hint as to 
a permanent fix.  Maybe its not a big deal as it seems only to inhibit 
testing of the serialization library.

> I don't want to repeat myself, but I would recommend to revaluate
> some other components presented by Boost.Test. UTF would be give you
> and your customer much more whatever your testing needs are.

I don't dispute that UTF is better.  Its just that sometimes I want to make 
a test and I can't build the boost libraries without taking a big detour 
into bjam country.

Robert Ramey