Path: utzoo!attcan!uunet!hsi!stpstn!cox
From: cox@stpstn.UUCP (Brad Cox)
Newsgroups: comp.object
Subject: Re: testing object oriented programs
Message-ID: <5121@stpstn.UUCP>
Date: 27 May 90 14:41:40 GMT
References: <1990May20.154035.15064@axion.bt.co.uk> <54783@microsoft.UUCP>
Reply-To: cox@stpstn.UUCP (Brad Cox)
Organization: Stepstone
Lines: 32

In article <54783@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>In article <1990May20.154035.15064@axion.bt.co.uk> krichard@axion.bt.co.uk writes:
>>Features of OOP such as encapsulation and well-defined interfaces
>>no doubt facilitate the verification, validation and testing of
>>object-oriented programs.  On the other hand, others such as
>>inheritance and dynamic binding would appear to make testing more
>>difficult.
>>
In deciding whether object-oriented programs are more or less difficult to
test, we must be careful to not confuse the chicken and the egg. The chicken
is the object-oriented tools, where by 'object-oriented', I'm referring to
open universe languages (Smalltalk, ObjectiveC) that do not insist that the
relationship between parts and the whole be known and declared in advance,
at compile-time, as the universe is being created by the compiler. In
closed-universe languages (Ada, C++, Object-Pascal, etc), i.e. strongly
type-checked languages, all such relationships must be known and declared
at compile time.

Open universe languages simply provide support for solving open-universe
*problems* (collections of unknown components, pluggable software components,
software components marketplaces, etc).

But open universe problems are intrinsically more difficult to test than
closed universe problems, independently of the tools used to build them.

In other words, the testing difficulties arise from the nature of the problem,
not from the nature of the object-oriented tools used to solve them.

-- 

Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875
The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482