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.