[squeak-dev] Subclassing tests Style Question

Hi,

I have two classes say A and B.

B has a collection of A which is quite complex.

Laziness suggests to make BTests a subclass of ATests so I could reuse
the (lengthy) setUp of A in A tests. Something like

BTests>>setUp
 super setUp
 ..stick a copy ATests A into BTests B
 super setUp
 ...add a slightly modified copy of ATests A into BTests B

The gut feeling says BTests should not inherit from ATests if
B does not inherit from A.

But copying all that A setup code from ATests to BTests does not seem
right either.

Hey that's the first time I think using a Trait might not be that
bad??

Making a class with the only purpose to return initialised instances
of A??

Any advice is much appreciated!


Thanks,

Herbert

Hi Herbert,

Sounds to me like you should delegate set up to a helper class that is
used by both test case classes. Perhaps even a TestResource
(http://www.metaprog.ch/downloads/TestResources.pdf).

Regards,
Zulq.

Herbert König wrote:

Hi,


HK> Laziness suggests to make BTests a subclass of ATests so I could reuse
HK> the (lengthy) setUp of A in A tests. Something like

thanks Jerome and Zulq.

So it will boil down to a helper class.

A Factory is not needed anywhere except for the tests. A has 6
instvars, one of them an OrderedCollection with typically five to ten
elements (points) that describe a closed polygon. They will be entered
manually by the user or will be read from a file in the application.

A test resource sounds interesting but I prefer a simple class. And
cpu time is no problem here so I will create the objects the classical
way in each tests setUp.

Cheers,

Herbert                            mailto:[hidden email]

Hi Herbert and Zulq

>
> Sounds to me like you should delegate set up to a helper class that  
> is used by both test case classes. Perhaps even a TestResource  
> (http://www.metaprog.ch/downloads/TestResources.pdf).

I'd create a bunch of example methods on the class side of A (e.g. A  
class >> example1 and A class >> example2 ...) and a method which  
would return all of them:
A class >> examples
        ^{self example1. self example2 ... }

then you just call them in your test BTest -- or continue to write  
this example style, throw an assertion at the end here and there or  
even some post conditions or invariants.

To make this "monkey patching" as some might call this a bit more  
maintainable, ensure to put those extensions in some test package by  
prefixing the method category with sth. along the lines of  
"*MyPackage-Tests" to tell monticello not to include them in the  
"real code"-package but in some test package.

Then, of course ;-) , patch SUnit to collect those example methods  
and run them, after ordering them so that only the high level  
examples need to be called/tested.
I never came around doing so, though it is not that hard -- others  
did for Java:

http://www.iam.unibe.ch/~akuhn/blog/2008/04/jexample-quickstart/

Thanks Adrian!

Cheers

Markus