A few months ago in the Austrian alps I was skiing and attempting my second ever slalom run on my trip. Those of you that I have seen recently will now it didn’t end well!
I gathered too much speed, caught some ice and tore my ACL.
Since then I have to do some exercises each morning to prepare it for surgery. I tend to try and watch some interesting talks while I do this and make use of my “bonus” time. They are often TED talks but I had watched many of the latest ones so, super geeky, I switched to Go To Conference talks which are software talks – mainly based around web technologies.
I find it interesting to watch some of the talks that skirt the edge of the technical and understand how they can be applied to LabVIEW. This was certainly true of Level Up Your Unit Tests.
The talk is somewhat the story of a developers transition to a new testing tool and there is one piece that really appealed to me.
There is a concept I have come across before for a structure for acceptance tests called Given, When, Then. The idea is it clearly describes every aspect of a test situation:
- Given: The pre-conditions.
- When: The trigger or action.
- Then: What the software/system should do in response.
Given we have a high temperature alarm, when the user clears the alarm then an alarm should no longer show as active.
In the video Trisha Gee describes a test framework that was new to her that actually describes the tests in this structure which greatly helps with clarity and highlights problems with the code if any section gets too large. Ideally:
- Given is small. If it starts to get quite big this starts to sound more like an integration test and less of a unit test. It should also contain no tests – this is not the subject of the unit test.
- When is tiny. This should ONLY be the code you are actually testing.
- Then is tiny. This contains your actual tests and assertions. Given a unit test should test one thing there should only be one assertion here or multiple tightly related assertions.
Why Looks Matter
What struck me was that my unit tests – while quite effective – are a mess compared to my normal code. I tend to rattle through then and not give them the full attention that they need. This can hurt me when I have to return to them to understand why they fail.
So I have experimented by taking the descriptive structure of the framework that Trisha describes in the video and implementing it in LabVIEW. The idea is we want clearly separate sections for these with defined boundaries so I found flat sequence structures work well.
Let me give you a (kind of) before and after.
This is the old style. It works, well. However just looking at the code there are test cases spread throughout (5 in total) and it isn’t clear from the code alone what is being tested.
(Yes this is a different test, I haven’t rewritten all of my tests to this format)
Here it is much clearer what is just setup code, what is the code under test and then what the conditions are that we really care about.
It also makes it really obvious if I had tests that were really just checking that the setup has worked which is what some of the tests in the before case are doing (Sometimes this can be really useful though, I think the answer is though that this code should have been tested somewhere else – but I need to think this through more)
Now I really am running out of things to say on unit testing! I have a few more OO posts in the pipeline as well as a couple of tips & tricks posts that I hope to do this year. It has been very busy the past couple of months but I will be having some time off over the summer while they reconstruct my knee! So expect a few more posts then.
Thanks to the commenters below I wanted to include a couple of links.
- This template is now built into the VITAC toolkit at https://github.com/WiresmithTech/VITAC/releases (thanks for the prompt Fab!)
- Ivan’s tip below for adding this to the default class is great and I have this on all my systems now – http://kosist.org/2018/08/modify-default-vi-tester-testcase-template/