|
|
Boost Testing : |
From: Stefan Slapeta (stefan_at_[hidden])
Date: 2005-01-26 08:30:12
Hi Robert,
The problems you mentioned are not only caused by the serialization
library, even if its testing is very time consuming. During the tests
for 1.32, I often asked myself what will happen one day when the number
of libraries in boost has grown considerably; one day we will arrive at
a point when we have to think about two alternatives: splitting boost
itself into components and separating components that have no incoming
dependencies, like python (which is, IMO, highly desirable) or at least
breaking the testing procedure into smaller parts.
Stefan
Robert Ramey wrote:
> In the next day or so I will be checking my recent changes to the
> serialization library. Aside from a few small bug fixes and documentation
> tweaks, the major difference is the addition of DLL versions of the library.
> This ias resulted in doubling the number of tests as most tests are now run
> against the DLL as well as against the static library.
>
> The amount of time for testing the serialization library could be almost
> double the current time. This is somewhat ameliorated by the fact that the
> test Jamfile now avoids building tests and libraries that are apriori known
> to fail. For example, tests with the mingw compiler skip all wide char i/o
> rather than building and failing as before.
>
> I'm aware that the time to test the serialization library is considerable
> and I'm concerned this might create a problem for some testers. For this
> reason I am posting this message.
>
> I should say I don't think its necessary to re-run the whole serialization
> test suite every day but rather just when I've made a change. I realize
> that its possible that running the serialization tests represent a test of
> the libraries on which the serialization libraries depend upon, but I don't
> believe that its an efficicient way to do this. Of course, I have no
> problem with the tests being run as often as the tester desires.
>
> Robert Ramey