Boost logo

Boost :

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-01-12 10:50:59


On 1/12/24 05:16, Robert Ramey via Boost wrote:
>
> a) Treating Boost "as a unit" and testing on this basis results in an
> amount of work which increases with the square of the number of libraries.
> b) Modifying libraries to pass tests in other libraries make one library
> dependent on another which might not be obvious.  Libraries should be
> tested individually as a unit to prove that the the implementation of
> the library matches faithfully implements it's expored interface.
> c) If this is done, it is guaranteed that errors cannot be introduced
> when libraries are composed.

No, it doesn't.

Even disregarding that you can't reasonably test everything, you're
forgetting that libraries change (yes, including the public interface)
and often affect each other through their usage, sometimes in
non-obvious ways. Suppose, a library A provides a unique_ptr
implementation (such as the one in Boost.Move) that supports a custom
deleter. That library may test that unique_ptr does use the deleter as
intended. But that doesn't guarantee that this will still work in
another library B that uses the unique_ptr with its custom deleter - for
example, because that deleter is defined in B's namespace and since it
is specified in unique_ptr template parameters, it now affects ADL.

Integration testing exists for a reason. If you're not doing integration
testing, you're getting a bunch of disparate components that don't
compose well or at all.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk