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.
3 thoughts on “Conversations about unit testing”
Thanks for sharing this post with us, I am looking forward to seeing what you came up with. I am also digging in my notes on how to inherit JKI VI Tester Tests, I have done it, I will get back to you with that.
Please consider posting a link to this post at the Unit Testing group at https://forums.ni.com/t5/Unit-Testing-Group/gp-p/5182
You will find a lot of the people who are highly knowledgeable in Unit Testing for LabVIEW follow that group.
Found it, Nate Moehring presented about it at the LAF meeting and you can see the section regarding JKI VI Tester inheritance on this video, I already set the video to start playing at 52:56 which is when he started this topic https://youtu.be/ol_evUatwPE?t=3176
This video was also included in a post at the Unit Testing group at https://forums.ni.com/t5/Unit-Testing-Group/Unit-Testing-in-LabVIEW/gpm-p/3762773
Thanks for sharing this post and writing about unit testing requirements.
Is the file config used for test vectors, with a range of inputs? Or did I miss the point?
As to class inheritance, if I understood you correctly you wanted your test class/case to inherit from the class you wanted to test, rather than having a hierarchy of test cases?
What’s the reason for this? (Again, I’m sure I’m probably missing something obvious – in the latter case I’d guess shared setup/teardown or perhaps generation of inputs being modified)