Getting started with the Unit Test Framework

[BertMcMahan]

I have one particular application that could REALLY benefit from unit testing, as it's heavily "algorithm" related and I need a ton of corner cases tested to ensure that future updates don't break older code. This code is also OOP, so I wound up with a lot of setup and teardown code. Unfortunately, I came to the same realization that the built in toolkit is only good for minimal stuff, as I'd have code fail tests, then close/reopen the project, then it'd pass the same tests! There was some kind of issue that I never could figure out that would cause the part that set the front panel values to fail some of the time. It seemed like it was related to having the VI open when I ran the test, but I couldn't ever pin it down. Eventually I gave up 😞 Glad to see there are other toolkits out there, as I definitely need the tests but the built-in system was way more trouble than it was worth.

[Brett_Percy]

>> I noticed the article says you prefer VI Tester (back in 2020) but now you're liking Caraya more. Why the shift?

It does vary a bit depending on the application - and as BertMcMahan says, if there's a bit of common set-up and tear-down then the structure of VI Tester is helpful and worth taking advantage of

I've mainly started using Caraya for turning ad-hoc test VIs I was already building into 'proper' unit tests.  You can always build shared helper VIs for Caraya tests, it just doesn't help you out there

Cheers
Brett

[OneOfTheDans]

---

@BertMcMahan wrote:

I'd have code fail tests, then close/reopen the project, then it'd pass the same tests! There was some kind of issue that I never could figure out that would cause the part that set the front panel values to fail some of the time.

Ok, two years later I think this just happened to me, and I think I know why!

I had "Unchecked" some of the inputs, but that didn't seem to do anything, and if I reopened the Unit Test dialog everything was always checked again. I figured it was just cosmetic thing for bulk selecting.

NOPE. If an input is unchecked, the Unit Test Framework will not set that input. I'm not sure if it uses the data type's default value, the VI's default value, or as I suspect, the previous value. Previous value would explain why your tests failed "some of the time".

But there's a bug in the dialog (at least in LabVIEW 2020 SP1), which always shows the boxes checked, regardless of what's really in the .lvtest file. The dialog will look correct, but it won't be setting your values.

[BertMcMahan]

Holy cow. If that's true, that's a REALLY big bug.

I got rid of my unit test framework stuff a while back so I can't test it quickly, but if that's truly the bug I'd be tempted to give it a shot again. But it was a lot of work to get it rolling, and it's lost my trust once already... it's hard to want to invest the kind of time I need to get that particular framework rolling again now that I've moved on.

Thanks for the update though. If you can make a reproducible case to send to NI I'm sure they'd appreciate it.

[OneOfTheDans]

I just tried this again in LabVIEW 2025 Q3 and the checkbox bug is gone. The dialog correctly shows whether or not an input is enabled. And I confirmed that unchecked will use whatever value is shown on the Front Panel.

Even if that bug is what caused your troubles (esp. copy/pasting .lvtests or duplicating cases with hidden unchecked boxes), I wouldn't recommend investing any time in NI's Unit Test Framework. The UI is clunky, it's poorly documented, and it doesn't even support Maps/Sets (6 years old by now?) or Classes (15+ years?).