Re: [platform-core-dev] Testability experiment

[Magiel Bruntink <magiel@xxxxxxxxxxxxxxxxxxxxxx>]

On Wednesday 14 May 2003 23:56, John Arthorne wrote:
> I think your lack of response on this is because your scenario is very
> artificial.  We don't write tests for individual classes, we write tests
> for units of functionality.  Typically this functionality spans several
> classes, and it doesn't make any sense to test the parts individually.  In
> fact, most of the classes you list don't really have any isolated
> behaviour that you can test. For example, StoredObject is an abstract
> class.  NodeInfo is just a data structure with accessor methods.
> MissingBuilder is a nested class that can't be tested outside the context
> of its enclosing instance.CollectSyncStatusVisitor can't be tested without
> also testing the corresponding "accept" methods. Testing an exception in
> isolation (IndexedStoreException) also doesn't make sense.  If you insisted
> on an ordering despite this artificiality, I'd probably use some
> source-based metric like file size or method count to order them.  This
> would either give hollow validation of your theoretical results, or
> contradict them for no good reason.

Hi John,

Thanks for your response. It seems to me you are suggesting that no
unit testing is done for Eclipse, am I correct? Perhaps I should have mentioned
that the focus of my research is on unit testing, I apologize for the omission.

The selection of classes I made is somewhat arbitrarily based on the calculation
of a number of source-based metrics. I am now aware that a number of these classes
are a bit extreme in the sense that they do not have a well-defined functionality on
their own. Thank you for pointing that out to me.

Yours,
Magiel Bruntink