Can we add an optional input to the Pass If Error and Fail if Error for error number?

[stagg54]

Sometimes you are expecting a very specific error.

With the pass if error, you want it to pass if that specific error is raised, but only if that specific error is raised. If some other error is raised, you want that other error to propagate.

VI tester does support this. Sorry to keep comparing LUnit to VITester, but it is what I know.

Here is what it looks like in VI Tester.

If you make that input optional, then it should be backwards compatible.

Of course, there is a workaround in that I can just break down the error cluster myself and check the code manually.

[antsundq]

Thanks for providing the feedback and suggestions Sam.

I have never found the need for this myself, but if you think it is useful I'd be happy to add the feature as it would not break anything.

I do like VI Tester and the initial goal for LUnit was to have feature parity with it. Let me know if you have other feature ideas.

[antsundq]

Added two new assertions "Pass on Specific Error.vi" and "Fail on Specific Error.vi". Decided to not change the existing assertions as they probably meet 90% of use cases. Adding the optional terminal clutters the API and the additional logic adds some very slight overhead.

The new assertions are in a new subpalette called Advanced Assertions. I feel there are likely more assertions which could be useful. One which I use a lot in LMock is "Pass on match" for string comparison, i.e. pass if regex is found in string.

The new assertions are available from this release: https://github.com/Astemes/astemes-lunit/releases/tag/v1.4.15

/Anton

[stagg54]

I very much like the idea of "Pass On Match"

another one to consider might be "pass if set match" - I don't know if that is the right name, but I often find myself testing VIs that output arrays (that probably should be sets instead) where I don't care about the order. I find them cumbersome to test, because I have to take the output and turn it into a set.

[antsundq]

Hey, I added the following assertion as well:

This works with arrays, sets and maps. For maps it checks if the key is found in the map and for sets/arrays it checks if the element is found within the set/array.

I just updated the VIPM release and the new assertions are included there.