public TestBlabla(AbstractBaseClass classToTest)
{
…
}
an the input for classToTest are the subclasses.

@Perryn – yeh I was wondering whether the struggling was deserved for using inheritance as well Might actually have been better off using composition.

If I ever create abstract classes, I tend to have a test hierarchy that mirrors them.

So if, for instance I have three classes called:
Animal
Cat
Dog

I’ll create three tests:
abstract AnimalTest
CatTest extends AnimalTest
DogTest extends AnimalTest

(If necessary, I change these names so that whatever build I’m using doesn’t pick up the animal test).

The AnimalTest describes the behaviour that’s common to all animals, and uses an abstract method to create the animal. The CatTest and DogTest then override this method.

This describes the common behaviour quite well, while ensuring that both the Cat and Dog carry out their respective responsibilities here.

The methods in the abstract AnimalTest are never run on their own, only as a component of the other two.

1) use composition instead of inheritance

2) If you must use inheritance, use it in your tests too. Create an abstract *test* class that tests the similar behaviour and then extend that class for each of your tests. You would then break three tests with a change but you can fix them all in one place.

In .NET you would have to create an actual class to do it which is not quite as clean as in Java but it would still do the job.

I had written that option off because it feels kinda nasty though since that class your now testing is there just to help testing.

Maybe it’s just the punishment you get for using abstract classes

I don’t work with .NET though, so I’m not sure if such thing would be possible in your case.