Boost Testing :
From: Robert Ramey (ramey_at_[hidden])
Date: 2005-04-15 14:11:58
Martin Wille wrote:
> Robert Ramey wrote:
>> The amount of resources could be much reduced by only testing
>> libraries that change. I havn't uploaded changes to the
>> serialization libraries in weeks, yet still the tests are run every
> I think there were many changes to libraries your tests depend on,
> e.g. shared_ptr.
>> I'm not sure what the motivation for this is. If its because the
>> serialization library exercises other libraries (which it does) it
>> would indicate that what's really needed are more tests for other
> I don't agree. E.g. testing the serialization of shared_ptr is
> unrelated to testing shared_ptr's own features. However, since your
> code obviously depends on the code of the other library, a change to
> the other library might break your code. So running the test makes
> sense in that case.
hmm - shared_ptr isn't the best example since the current share_ptr
serialization is dependent upon share_ptr implementation but the shared_ptr
serialization is part of the serialization library.
It should be:
if shared_ptr serialization depends upon shared_ptr implementation - it
should be part of the shared_ptr library tests.
if shared_ptr serialization depends only upon shared_ptr interface, it
can be part of any library.
Things aren't this way now but we're trying to change that.
> This would be different if the Boost libraries
> wouldn't have a strong tendency to implement significant portions of
> their code in headers (we won't change that). With what we have, any
> change in a header file could be an interface change (and therefore
> require testing of depend libraries) or just an implementation
> change. There's no automated way of telling the difference.
Well, here is the problem. Changing the interface is a really different
kind of thing than running a test. It seems expendient to just make the
change and run all the tests to see what breaks. This has happened a couple
of times recently. But I don't think it should be regular policy. Of
course sometimes we do need to run the whole thing (including release as
well as debug). But I would expect that that would be an occasional thing
rather than every night.
> Make your tests (or even the library) simply #include a header file
> with only a comment in it. Change the comment, commit, and the tests
> will be re-run.
As far as I can tell, the tests are being re-run in any case.