Revise IO test class hierarchy to employ composition over inheritance

[lumip]

The current TestSetup classes were implemented with only a very small number of tests in mind and rely on inheritance to overload specific message (typically only pulse generation).
The current situation however exposes two drawbacks of this approach:

• Test classes mainly differ in pulse generation and DAC setup. These vary indepently from each other which leads to a mulitplicate increase of required test classes.
• Test classes overwrite methods of the DefaultTestSetup class with essentially the same code (which partly results from the first point).

To alleviate these issues, composition should be preferred to inheritance, meaning that to change how, e.g., pulse generation for a specific test works, the class should not be inherited and modified directly but be parameterized via pulse generation objects. I will add a UML diagram with explanations shortly.

[lumip]

UML diagram for a TestSetup class that relies more on composition:

Basically, the setup of pulsegroups and the DAC is removed from the class and now handled by implementations of the interfaces TestPulseFactory and TestDACFactory in somewhat like a Strategy Pattern. These provide all the data that frequently varies between test instances and are easily interchangeable. The TestSetup class obtains the required objects from the factories (which are provided to it in its constructor) and executes the test.
I deemed the initVAWG and evaluate function as unlikely to vary, so I left them as member of TestSetup. However, if need be, the same changes can be applied to them.

I will implement this in the next two or three days.

[pbethke]

expected data depends on the pulse, the masks and the mode, so calculating the expected data can only really be done in TestSetup in this diagram. Everywhere else there is information missing.

[lumip]

Indeed. I put some more thought into it today and noticed the same problem.
I think I have figured it out now:

Implementations of the abstract class TestConfigurationProvider provide the Mask for the test and know how to invoke the TestPulseBuilder interface functions to obtain a pulse group suitable for the mask (in their implementation of the abstract function computePulseGroup). TestConfigurationProvider offers implementations for methods that are identical for different mask setups, e.g. the setup of the DAC object.
Implementations of the TestPulseBuilder interface are used for construction of the pulse groups. Invocation of addPulse() creates a new pulse and adds it to the pulse group. The mask parameter is used to obtain period, start and end time (so it must be the structur of a periodic mask; a table mask has to be splitted in the implementation of the corresponding TCProvider). After finishing the construction of the pulse group, it can be obtained alongside with the expected data for the DAC operation via the respective getter.
Furthermore, TestPulseBuilder implementations know and export the error thresholds and of course the DAC operation.
I think this should work and be sufficiently flexible. Some of the getter-functions may be realizable as abstract properties in Matlab but I could not visualize this in the diagram.
I also declared the init-function of TestSetup as protected. I think this should be called by run() internally to exclude the possibility of incomplete object initialization.

If there are suggestions for better names, I am happy to accept.

[pbethke]

This looks promising. Do you need help with the implementation?

[lumip]

I have already begun and done the most of it. I think I can finish the rest today in the evening.

[pbethke]

are you also writing the matlab unit tests (#10) ?

[lumip]

Currently not. This can be done by someone else or I can tackle it after I've finished this issue here.

[lumip]

I'm done with the implementation of the hierarchy outlined above. However, I think I will add some comments/documentation in the near future, so I will not close this issue right now.
During implementation I also made some minor changes to the class structure (e.g. TestPulseBuilder is now an abstract class because otherwise its implementations would have to perform some redundant operations..). I will upload an updated diagram later on.

[lumip]

As announced previously, here is the updated class diagramm: