Daniel Ford

I recently became a comittter on the Open Health Tools Model-Driven Health Tools project (MDHT) https://mdht.projects.openhealthtools.org/ The project is leveraging the Eclipse Modeling Project, specifically, UML2 and EMF, to produce implementations of the HL7 standard.

My first contribution to the project is an extensive set of JUnit 4 test cases that exercise OCL constraints specified for objects in the  model.  Most of the tests are fairly simple, basically setting up configurations where validation is expected to fail or it is expected to pass, and verifying the expected outcome.  To my great satisfaction I was able to catch dozens of real errors, mostly things like typos in the OCL, but also errors in which OCL statements were improperly processed during code generation and ended up mangled in the result (a surprise).  The tests even tripped across errors in OCL processing  itself when particular invalid objects were erroneously validated as correct (another surprise).

The real story, however, was the design challenge needed to create the tests.  We don’t usually think of test cases as being particularly hard to create, and they usually aren’t, but in this case I had a particular problem.  It turns out that the HL7 standard has a few interesting attributes, one of which is that it is possible to define new types of “documents” by referencing an arbitrary collection of parent “templates.”  The practical result of this is unconstrained multiple inheritance.  This is something that the EMF can handle, but it makes testing a potential nightmare.

The main problem is that the classes to be tested could and did have somewhat arbitrary collections of things to be validated, but because Java doesn’t support multiple inheritance, it isn’t possible to simply mimic the EMF supported multiple inheritance hierarchy to create the matching collection of tests.  To complicate things, many of the tests are very similar, often only varying on just the particular field participating in validation and the exact OCL expression.  These two attributes combined to create the potential for massive redundancy in the test cases.

What to do?

The strategy came up with was to create a collection of independent test case “templates” that could be customized using EMF reflection to test the exact combination of field and validation.  These templates were implemented as abstract (static inner) classes.  Anonymous instances of these template test case classes were then created as appropriate to put the right set of tests together to match what was inherited in the EMF generated code of the class under test.  These anonymous instances were initialized with details like the name of a feature to customize the template.  The collection of anonymous test case definitions were then grouped together for a particular class being tested by defining them in a static initializer of an array defined in the JUnit 4 test case.  That class then only had one “test” which had the simple job of running through the collection of anonymous test templates, triggering each one along the way to do its thing.

The end result worked nicely, arbitrary tests could be combined to adapt to the whims of document design allowed by the HL7 standard, and they could be specified in a simple and consistent pattern.  A potential explosion in test redundancy was avoided by using the Template design pattern and exploiting the capabilities of the Eclipse Modeling Framework to do reflective accesses.  The only downside of this approach seems to be that the count of tests performed by JUnit seriously under reports the actual number of tests performed as each JUnit test can actually trigger the execution of dozens of test templates.