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.

I was recently reminded of the disconnect between organizational image and organizational reality. In software development organizations one often sees a professed focus on productivity and quality. Sometimes this is bolstered by the sincere adoption of some kind of “development philosophy” that has some spiffy name like “agile,” “srum,” “pair,” or “test driven.” Each approach has some value and the best developers and organizations adopt what works. The problem however, is that many stop there and don’t really think about what would truly make their efforts more effective and productive.

One practice that I’ve encountered, and have tried in practice, is to make it as easy as possible for a new person to join a software development project. This is a simple practice that can payoff big by getting new people to be productive as soon as possible. For open source projects, it’s pretty much a requirement for attracting other developers, because if it is hard to join a project, they’ll simply move on to something else (and you’ll never know). The surest way to do this is to codify the project’s tacit knowledge in an “immigration” document. This is a manual or wiki that you give to a new person that explains EVERYTHING about the project other than its design (and maybe a bit of that too). For instance, simple things like the names of the other developers, their contact information and the parts of the project that are their responsibility should be included. Also, a complete inventory of the tools in use, their versions, where to get them and how to install and configure them is incredibly useful to a newcomer. Administrative trivia is also essential; things like how to obtain an account, where the repositories are, the names of servers and where they’re located, and anything else that “everyone” just knows. A “starting out” check list is also a big help. This is step-by-step list of tasks for a new person to execute, the basic idea is to get them to be instantly productive by setting up their environment without any kind of drag on the rest of the team. The most important component of the immigration document, however, is an accurate, up-to-date explanation of the project’s build process. Why? Well, first, it means that the project actually has a build process! Second, it gives the broadest, least ambiguous, picture of the system being developed. The build process is also a reflection of a capabilities and professionalism of the organization that created it and it sets expectations for the project newcomer, and you want those expectations to be set to the max from day one.

This last point actually cuts both ways, if you’re a developer interviewing with a company and they get to the point where they say “Do you have any questions for us?” You should sit up and start digging for information about their build process. If it involves some guy running between two ancient PC’s with a couple of floppy disks, don’t expect to show up on the first day to a desk, a chair, a computer and the necessary accounts already set up; you shouldn’t expect an immigration document either. However, if the process is completely automatic, look knowingly impressed, throw them a compliment, and then ask to see a copy of their immigration document. If you get one, say “Wow! Where do I sign up?” If you get a blank stare, be nice and explain, interviewers love candidates that that can teach them something.

After many years of effort, Version 1.0 of STEM was approved for release by Eclipse.