Distributing Test Doubles and Mocks

One of the questions that came up in our recent Unit Testing Workshop was:

How do I distribute reusable test code such as Test Doubles and Mock Objects?

This question caught me by surprise. It wasn’t something I had really thought a lot about. I had typically just been making them each as I went. The idea of distributing Test Doubles and Mock Objects might catch you off guard if you are coming from text-based languages. Many languages allow you to create Mocks and sometimes even Test Doubles on the fly. In LabVIEW that is not possible. You must create an actual .lvclass and the associated method VIs for each.

Mocks are rather easy to create using the toolkit that I created, so reusing them doesn’t really buy you a ton, except that it saves you from running the scripting tool. Creating a programmable Test Double though can take a fair amount of effort as there is currently no scripting tool to do that for you. So they certainly make sense to distribute.

Use Case

The situation the student described was as follows: He had a whole bunch of reuse libraries packaged as PPLs. Now let’s assume he had a driver for an instrument, say an O-Scope. His O-Scope has unit tests to make sure that it sends the correct commands to the instrument and parses the return data correctly. That is great.

However, this student had multiple other PPLs in various projects that utilized the O-Scope PPL. How to test those? That would typically require a Mock Object or Test Double. Why create multiples? This student had the foresight to realize that he could create one Mock Object and One programmable Test Double and Distribute them to all of his developers. The question was how best to do that?

Solution

Here is what you would need to distribute – the PPL for the interface along with separate classes for any Mocks or Doubles. NOTE: keeping them outside the PPL makes it easy to keep test code out of production.

We brainstormed as a group and here is the best solution we came up with: Distribute the Mock Object or Test Double as a separate class along with the Interface. Assuming that you had an Interface (or Virtual Parent class) for the O-Scope (ie. some sort of HAL), then you would have a separate test class (either a Test Double or a Mock Object) outside the PPL, that you would distribute to your other developers along with the PPL. Having it separate would allow you to keep the test class out of any built code.

Learning Moment

I like teaching classes and writing blog posts, because I always learn things. The question in the class got me to think about distributing Mocks and Test Doubles. In writing this blog post I actually discovered something else. I’m kind of new to using PPLs. I’ve only adopted them recently. I hadn’t played with using my Mock Object Tool with PPLs. It doesn’t work with classes inside PPLs. Fixing that is on my list of things to work on in 2020. As a workaround, you can use the tool on the original source class and then change the inheritance to point to the class inside the PPL. Unfortunately, that only works if you have access to the source.

2 Comments on “Distributing Test Doubles and Mocks

  1. Sam; I have used PPLs extensively since when they were first released. I also suffered the pain of builds and inter-dependencies like everyone else, which made me wonder whether NI would ever have a better vehicle for this in LabVIEW classic rather than the work-arounds that better have come up with. Unfortunately, it appears NXG will kill that off unless they back-port gcomps.

Leave a Reply

Your email address will not be published. Required fields are marked *

*