Re: Boost downloads and JFrog

From: Robert Ramey (ramey_at_[hidden])
Date: 2024-01-12 18:12:03

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