On 1/12/24 2:50 AM, Andrey Semashev via Boost wrote:
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)
Changing the public interface is a serious mistake for a library. Ideally, library interfaces implement concepts or compile time asserts on types and run time asserts as pre-conditions. So it this is unavoidable, there is less damage to users who have mistakenly depended on this particular library. I don't think it's fair to expect users to "just deal with it" when a library interface changes.
and often affect each other through their usage, sometimes in non-obvious ways.
Maybe. If so, I think this would be a design mistake.
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.
I don't think its appropriate to expect any code which uses unique_ptr to have to specifically test unique_ptr with a users particular custom deleter. unique_ptr should specify it's type requirements for a custom deleter which can guaranteed at compile time and should work with any implementation of a custom deleter which fulfills these requirements. This will guarantee that unique_ptr cannot fail. Of course this doesn't mean that one's custom deleter should not be tested. It should, but independently of anything else. Personally, I'd specify a custom deleter with the namespace name to avoid ADL surprises.
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.
Exactly wrong. Integration testing test a very small subset of combinations of cases. I only gives the illusion of correctness. The only way to provably correct composition is to formally and completely define interfaces, and test each implementation to guarantee that it correctly implements that interface. If integration testsing fails, it must be because some component has not followed the above rule. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost