Caraya test framework for LabVIEW – convert your VIs to test code!


In my previous post, I’ve slightly touched unit test topic in LabVIEW, particularly – JKI VI Tester. But, as I’ve mentioned there, there is another unit test framework from JKI – which is Caraya test framework, designed by Tomi Maila (as it follows from this presentation from Jim Kring).

To be more precise, JKI calls it “Assertion and unit test framework for LabVIEW”, because it evaluates test result by assertions result. Assertion – is some condition, what must be met at the particular place of the code; otherwise program will raise an exception. I’m not gonna describe it in details – because honestly, I don’t have such deep knowledge – but if you would like to know more about it, you should refer to “design by contract” topic.

So, let’s take a look at Caraya test framework. It is also free for usage, and can be installed from VIPM.

After installation, one can find Caraya functions under JKI Toolkits pallete.

What are the features of Caraya? Main one is – that one can easily “convert” his code module into test module, just by placing couple extra functions on the block diagram.

What many LabVIEW programmers do – I believe – while creating some code modules, is also creating of some dummy VIs, where we test our code modules. We call them as subVIs, add inputs, check the outputs. So the idea of Caraya is – to make those “playground” VIs (or even our “main” code modules VIs) into test VIs, which will be tested by Caraya test framework.

Let’s check some simple example of that.

So, imagine that we need to create one code module, which will remove duplicates from numeric array. It has to meet the following requirements:

  • If input array is empty, error code 5001 must be generated;
  • If input array does not contain duplicates, array should not be modified on the output;
  • If the input array contains duplicates, duplicates must be removed from the array.

So, based on this, let’s create two code modules – one will check if array is empty and raise an error; and the second one will use the first module, and also do main algorithm of duplicates removing.

VIs templates are prepared, so we can – following test driven development – create tests for them.

Let’s create one empty VI, and put there couple functions from Caraya pallete: Define Test.vi, and Asser Error.vi. Now, we can put inside our vi-under-test, and connect inputs-outputs.

That’s it, our test VI is ready!

Let’s run the VI.

And now, we see Caraya window, with test results. And we see that test is failed – b/c our module is empty. Let’s close this window, and let’s create another test.

For this, we will create new VI, and put there already one Define Test.vi, and two Assert Equal_Variant.vi functions. Now, inside of this test VI, we will implement verification of two conditions – when input array does not contain duplicates, and when it does.

Couple clicks, and the second test is ready.

Let’s run it also.

It fails, and in Caraya window we see description of those two tests. If we double click on that, it will bring us to our test VI.

Now, it’s time to implement our VIs-under test.

When they are prepared, let’s now run both test VIs, one-by-one.

All tests are passed, and it means, that we have met all the requirements!

So, what do we see now?

  • We don’t need to start any extra tool – Caraya window is opened when we run our test VI.
  • It does not take long time to create the test – we need just to define test, and define assertion condition.
  • One test VI, indeed, can contain as many tests procedures, as we want. Or, we can implement each test in separate VIs.
  • Execution of tests is extremely fast!

But, maybe you miss the report? Not a problem! Let’s create Test Suite.

For this, we’ll create the third VI, and put there our two test VIs, plus Define Test Suite.vi and Destroy Test Suite.vi.

Basically, Test Suite can be used to generate test report – because we can bundle execution of several test VIs together without it; all we need is to put all test VIs into one VI.

But, Define Test Suite.vi allows us to run tests in “silent” mode, when we will not have Caraya window opened after test is executed (use flag “Interactive”). If tests will fail, then error will be generated on the output of assert functions.

By the way, if for the tests we will not use Define Test.vi, then also, no Caraya window will be visible – instead, if test will fail, then error will be generated (by default, error code is 1).

So, let’s now run our Test Suite VI, and check test results, and whether test report is generated.

Test report format is like this.

Finally, at the end, our project looks like this – couple main VIs, and couple test VIs.

Basically, that’s it – small intro to Caraya.

But this topic is not full, because we didn’t touch TDD project example, which one can install from VIPM. This project contains sample project, which uses Caraya. It is greatly described in this post – TDD in LabVIEW – a Caraya approach, so I highly recommend also to go through that blog. Because then, you will know how to easy implement running of Caraya tests while pre-build action, for example.

At the end, I must say that Caraya is also available in the GitHub repository, where one can download it, or fork and contribute; and report issues/bugs/ideas for improvements.

So, I can say that Caraya is really easy to use and understand tool, which allows you easily create tests for the code. And the strategy for it could be different – create separate test VIs (as I showed in this post), integrate assertions to the main code, and then run/disable it by project Conditional Symbols (as TDD project example shows), or somehow else.

But as the result – by reusing our playground VIs, what we create every day – we can get fast and reliable unit tests, which will help us to improve and assure quality of our code.

The example code project – Caraya Example.zip, LabVIEW 2013, SP1.


Logo image is taken from http://blog.jki.net/community/caraya-a-new-take-on-labview-unit-testing.

Leave a comment

Your email address will not be published. Required fields are marked *