Given, When, Then In LabVIEW Tests
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.
Descriptive 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.
For example:
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.
Before:
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.
After:
(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.
UPDATE:
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/
Omar
July 15, 2016I had not heard of this but it really seems powerful. It especially makes sense for me in the context of functional/integration/acceptance tests and even in HIL test planning and development. I think that for unit tests, the goal should be to aim for even more brevity – as in “given, then” because it seems to me that the “when” part should be fulfilled in a different way for unit testing. I think that the “when” part means you need more unit tests (or possibly more test suites) so that the “when” cases are all tested as individual units. That might be a language artifact but I think that it might also lend itself to even more simplified unit test cases.
FYI I just wrote an article (http://www.labviewcraftsmen.com/blog/tdd-in-labview-a-caraya-approach) on TDD for bowling score keeping. It seems to me that the test cases in each of these tests fall into “Given X, Then Score = Y”. The “when” should be fulfilled by adding more tests so that the “X” represents each condition I need to test under (testStrike, testStrikeInBonusFrame, testStrikeAfterGameOver, etc). The “when” for these cases is the state of the game prior to the next roll.
In your example above, I would consider whether the “Given” code should migrate to a test setup or test suite setup so that the “Load” method can be tested in a variety of “when” conditions without rewriting the actual evaluation.
Pingback: Modify default VI Tester TestCase template
Ivan
August 10, 2018Greate approach; I use it now accross the projects’ unit tests. Also, I’ve briefly described how to modify default VI Tester Test Case template, to have this “Given, When, Then” template already included – http://kosist.org/2018/08/modify-default-vi-tester-testcase-template/.
Fabiola De la Cueva
September 22, 2018Hi James,
I was pointing out someone to your VITAC toolkit and mentioned that it included the Given-Then-When template, then I realized that this blog post does not have a link to that toolkit. I suggest you add it to the original post, that is a very useful toolkit for LabVIEW programmers interested in unit testing.
https://github.com/WiresmithTech/VITAC/releases
Thanks again for sharing your knowledge with us.
Fab
James McNally
September 25, 2018I’ve added it in – thanks for the prompt, good point!
Pingback: Modifying VI Tester template
Pingback: Modifying VI Tester template - Kosist blog