So, I’m guilty. I had been spending too much time doing “Cowboy Development” and hadn’t been writing those unit tests like I should. It caught up with me the other day, so now I’ve been spending more time than I care to admit writing unit tests instead of new code. (I’m also finding more bugs than I care to admit, but that’s a different conversation.)
As it should have, this sparked a conversation with my tech lead about why I /wasn’t/ writing tests to begin with. I thought about it quite a bit, and decided it boils down to the fact that my project traditionally used a home brew unit test framework that I was unfamiliar with. So, I was given homework to learn it.
(For some context, my project is a bit unique where we working in a large code base developed, and still owned, by another team. I’m on a very small team that is working to extend the existing code in ways the owning team isn’t actively pursuing.)
I talked to the owning team and dug out the documentation they provided. It turns out they’re running a nose based executor that uses VI Server to run test VIs. In terms of an actual LabVIEW “framework,” there wasn’t much there; just a template test that had the required con pane and some descriptions of how the outputs should be formatted.
It clearly works for them, but I wasn’t a huge fan, so I started looking around for a better option to recommend as a replacement or supplement. I looked a lot and narrowed it down to two primary options: JKI VI Tester and NI’s Unit Test Framework.
I had the following expectations of a replacement:
- Built-in file based parameter storage and specification. No reliance on default control values or constants for test inputs or expected outputs.
- Based on object oriented principles. Ideally it would allow my test to inherit from my class under test.
From what I can tell, neither of these options fulfill both of these requirements. NI’s does allow me to store my test data in a file, but doesn’t play well with OOP.
JKI’s doesn’t seem to have any built-in parameter storage options, but is Object Oriented. Unfortunately, I still don’t see any way making my test inherit from the class under test.
Before I go down the route of describing the solution I came up with, let’s take a break for a discussion:
- Am I missing something with the JKI option? I feel like someone smarter than me must have found solutions for my parameter storage and inheritance concerns.
- I only listed the two dealbreaking concerns that I couldn’t find workarounds for. What’s on your wishlist for a unit testing framework?
- Is having the actual test execution engine in LabVIEW important to you? Or is something like the nose framework OK?
Let me know what you think.