|
|
Boost Testing : |
From: Martin Wille (mw8329_at_[hidden])
Date: 2005-04-15 12:35:47
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 night.
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 libraries.
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.
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.
> Using one library to test another isn't really running a test - its more
> like the old method of just letting the application run and debugging it as
> a whole.
>
> What is need is a reliable test dependency scheduling. Also we would need
> an "escape clause" whereby the developer might request running the whole
> suite event though the automatic dependency doesn't require it. This is
> needed in some cases like when a Jamfile is changed.
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.
> Also, the shared libraries are not the static libraries just recompiled in a
> different way. I was surprised at how many changes were required to make
> the serialization library build as a shared library. There are still a
> couple of test cases that fail in the shared (dll) version and pass in the
> static version.
That's why I'd prefer shared library based testing over static library
based testing. Going the shared to static route usually is a lot easier
(with the exception of Boost.Thread).
Regards,
m