Boost logo

Boost :

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-01-22 12:45:10


From: "Peter Dimov" <pdimov_at_[hidden]>
I wrote:
>> For example, if CheckingPolicy doesn't
> interact
> > with any other policy, a suite can test all CheckingPolicy
implementations
> > using some arbitrary choices for the other policies.
>
> Yes; that'd be the way I'd approach the problem: as a white box.
>
> But a professional black box tester makes no assumptions; when a policy is
> intended to work as a SmartPtr parameter, it has to be tested as a
SmartPtr
> parameter.

Point taken. I guess the discussion becomes a pretty heavy argument in favor
of orthogonality. Frankly, I haven't realized that before, although
instinctively 'orthogonal' is 'good' :o).

Policies are nothing but glorified interfaces in conjunction with the
Strategy design pattern. They are more flexible because they allow exposing
types, not only binary signatures, and more efficient because they combine
at compile time. They lose in the binary standards aspect.

Anyway, you can imagine a class that stores and uses various interfaces that
provide functionality. The class is not aware on the way that that
functionality is implemented. How do you test such a class using strategies?
(I'm not an expert, but I suspect that the separation between those
interfaces eases the job considerably.) Same testing methods should apply to
compile-time combinations with policies.

Andrei

---------------------------------
Check out THE C++ Seminar: 3 Days with 5 Experts
http://www.gotw.ca/cpp_seminar/


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