Question

Imagine a system of filters (maybe audio filters, or text stream filters).

A Filter base class has a do_filter() method, which takes some input, modifies it (perhaps), and returns that as output.

Several subclasses exist, built with TDD, and each has a set of tests which test them in isolation.

Along comes a composite class, of an unrelated type Widget, which has two members of different Filter types (a and b), which deal with quite different input – that is, certain input which would be modified by filter a is passed through unmodified by filter b, and vice versa. Its process_data() method calls each filter member’s do_filter().

While developing the composite class, there emerge tests that check the assumption that Widget‘s filters aren’t both processing the same data.

The problem is, these sort of tests look identical to the individual filter’s test. Although there might be other tests, which test input which should be modified by both filters, many of the tests could almost be copied and pasted from each of the filter’s tests, with only small modifications needed to have them test with Widget (such as calling process_data()), but the input data and the assert checks are identical.

This duplication smells pretty bad. But it seems right to want to test the components’ interactions. What sort of options will avoid this sort of duplication?

Answer 1

Within one Test suite/class have a method

public void TestForFooBehaviour(IFilter filter)  {     /* whatever you would normally have in a test method */ } 

Then invoke this method from both the original test on the simple filter as well as from the composite filter. This also works for abstract base classes. Obviously FooBehaviour should be a meaningful description of the aspect of filters you are testing. Do this for each behaviour you want to test.

If you language supports duck typing or generics feel free to use it if it helps.