Re: [boost] [testing] Refactoring serialization tests, and possibly others.

From: troy d. straszheim (troy_at_[hidden])
Date: 2005-09-26 07:15:41

I have infrastructure built to do portability testing.  It is a lot of 
changes, flexible, and turned on by command line switches.  I know this 
doesn't help the current emergency, and I'm buried in chasing down bugs 
in the portable archive that I've found since I can now give it the full 
battery of serialization tests, and since I need to deliver this archive 
type ASAP, I can't switch to trying to do something intelligent about 
overall testing time within serialization.  I am collecting ideas, and 
trying to refactor things as I go to prepare for this "something 
intelligent".

But for now, maybe switch from carpet bombing to running only 
polymorphic xml archive (static), and non-archive-specific tests?  It's 
a quick hack to the Jamfile, would cut the run time down by 1/6 or so 
and still get pretty good coverage.

Testers could also get immediate relief by running with 
-sBOOST_ARCHIVE_LIST=xml_archive.hpp to get the same effect. 
(Apologies if that's obvious.)

-t

David Abrahams wrote:
> "Robert Ramey" <ramey_at_[hidden]> writes:
> 
> 
>>I should note that the serialization library changes only very 
>>infrequently - maybe once every few weeks.
>>
>>I would question re-runing the serialization library tests just because 
>>something that the serialization library depends upon changes.  
> 
> 
> We can talk about global policy changes after you fix the emergency.
> It's a lot harder to change the way we do testing and the rest of our
> infrastructure than it is for you to simply reduce the number of tests
> being run.
> 
> Please do what's required to bring the overall Boost testing time back
> down to something reasonable.
> 
> 
>>A main cause of this problem bjam dependency analysis re-runs all tests on 
>>Library X even if library X hasn't changed.
> 
> 
> No it doesn't.
> 
> 
> To reiterate:
> 
>    Anything that makes it very difficult and/or expensive for a tester
>    to complete a testing run needs to be fixed rather urgently.  
>