LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Unit test Queue/Notifier VIs discussion

Good morning,

 

I am currently setting up the CI/CD to automate the LV code verification with Jenkins & Azure Devops.

  

Currently I am looking to a way to unit test VI. I am creating my own software for CLI compatibly. Caraya framework / VI tester has too much overhead for my application & UTF has an impressive issue concerning flexibility and it is time consuming to create tests.

 

With clear inputs/outputs, UT is not an issue. However, I do not find a good and practical way to UT VIs that have internal LV communication processes (Queues, Notifier, Shared Variables etc..). Please see the example below.  

 

 

Capture.PNG

Question: how would you Unit Test this VI?

 

History: LV is used inside a medical tester and we had some issues that some messages hasn’t been send to the good queues/wrong message that causes a crash months after shipping. I let you imagine the rest ...

Requirements: I need to make sure the good message has been sent to the good destination

Assumptions

“has been sent” can be skipped as it is trusting NI?

“good message” is a simple comparison of the message sent before and the message received.

“good destination” is checking to which queues the message has been sent.

 

Since NI do not want to share in memory queues reference (to simulate DETT) it is hard to write a general queues catcher (it would be so easy, and problem solved in 5 minutes …).

 

UT is the first level of testing. Integration test (checking the entire message flow) will be next step and is out this topic. If I cannot make sure in UT that the message has been sent, it doesn’t make sense to continue the integration test.

 

I was thinking to mock the messages with a class or to wrap the queues library to have an “debug” mode (I will suggest that to the dev team for future machines). However, these two solutions would be very hard to implement and requires to changes thousands of Vis for every previous medical testers. The easiest solution is to create an indicators for the message. But this method might fail as I do not test to which queue(s) the message is sent. 

 

Hope it is clear since I have my head in that since months. Many thanks in advance for your help & suggestions 😉

 

 

Certified LabVIEW Architect (CLA)
Message 1 of 7
(528 Views)

I would ask myself this question - "what business logic do I need confidence in that could be subject to change?". Unit tests, after all, add the most value if they provide a safety net for unintended changes.

 

In your case, there is little benefit in testing the Queue API itself. It has been thoroughly tested by NI and thousands (millions?) of users. The real business logic here is (my interpretation of your VI):

 

1. A data packet is created, based on real-time ("sample data"?) and static (the hard-coded constants) state data.

2. The Queue API is called to enqueue this data packet.

 

My first reaction to test this is:

 

1. Create and instance of your class.

2. Obtain access to your internal queue

3. Pre-configure the "sample data"

4. Call the VI

5. Dequeue from the queue and check the packet

0 Kudos
Message 2 of 7
(495 Views)

Hello,

 

Thanks for your advice. The business value is huge as the dev team messed up many machines before due to poor testing (and coding!). UT would be part of a way larger new verification plan and as you mentioned, unintended changes cannot happened. 

 

I do agree that I don't want to test the queue API itself (interrogation mark in my first post), but more to create a "universal dequeuer" (as teardown) to catch all messages from every/specific in memory queues that doesn't require to be customised each time due to specific queue reference (that contains a specific datatype) in the subVI panel. 

 

So yes right now, I am also thinking to test VIs like the example the dev need to create each time customised setup & teardown VIs (or equivalent) to test this specific part. But it is then time consuming & can lead to wrong teardown (in case of multiple queues, messages order etc...). 

Certified LabVIEW Architect (CLA)
0 Kudos
Message 3 of 7
(477 Views)

I've seen people using helper queues added to dequeuer for testing that kind of things. Assuming you are using named queues.

 

pawhan11_0-1597210697291.png

 

0 Kudos
Message 4 of 7
(464 Views)

You're looking for data-polymorphism of queues (basically, generics) across VI boundaries. The closest thing LabVIEW has is vims of course but I don't see how that will help you in this situation. There's obviously the encapsulation angle to take as you suggested earlier but you've said this is an extensive re-work to enable this. 

 

If you have have common 'patterns' of code to test, then you could have a generic template (vit) for a test VI that includes Setup and Teardown/Cleanup. I typically use a similar AAA setup vit for my tests (primarily for VI Tester and our in-house framework GUnit which is very similar). That way there is no connector pane mismatch to worry about between calls. You would need to have one 'template' per 'pattern' of test you are performing and then replace the SUT calls for each new VI from the template. Any calls to the Queue API (eg. Dequeue to check data packet) would automatically adapt to changes based on the wire. 

 

Its hard to say much more about how feasible the idea is without knowing more about the objects involved, their construction, composition etc. in the system.

 

This makes test creation easier but not maintenance of those tests.

0 Kudos
Message 5 of 7
(444 Views)

"You're looking for data-polymorphism of queues (basically, generics) across VI boundaries".

 

It is exactly the issue. Or NI allowing to read any queues without knowing the datatypes of these queues (DETT is doing it so ..). 

Previous engineer did what I call “cow-boy programming” for the last 15 years and there is a clear lack of structure, otherwise I would have chosen your approached. But it gave me idea for a short-term solution for my issue (for now..). 😉

Copy a VI template and modify it via scripting to fit the queue data type. So dev engineer cannot mess around with the tear down VI and it is customised for a certain typedef queue: 

 

- a VI template tear down that creates queues, read it and analyse the message. As control I have a "Message Type To Change" control (whatever type) that is used to create the queue.

- a script that replace the "Message Type To Change" control with the chosen typedef.

 

This way I can test any queues without modifying the original code. Also, dev engineer do not need to create customised tear down "dequeuer" by them self. But I am not happy with this solution as it requires some manual action. 

 

So this topic remains open and any further help is warmly welcome

 

 

Certified LabVIEW Architect (CLA)
0 Kudos
Message 6 of 7
(365 Views)

"You're looking for data-polymorphism of queues (basically, generics) across VI boundaries".

 

It is exactly the issue. Or NI allowing to read any queues without knowing the datatypes of these queues (DETT is doing it so ..). 

Previous engineer did what I call “cow-boy programming” for the last 15 years and there is a clear lack of structure, otherwise I would have chosen your approached. But it gave me idea for a short-term solution for my issue (for now..). 😉

 

Copy a VI template and modify it via scripting to fit the queue data type. So dev engineer cannot mess around with the tear down VI and it is customised for a certain typedef queue: 

 

- a VI template tear down that creates queues, read it and analyse the message. As control I have a "Message Type To Change" control (whatever type) that is used to create the queue.

- a script that replace the "Message Type To Change" control with the chosen typedef.

 

This way I can test any queues without modifying the original code. Also, dev engineer do not need to create customised tear down "dequeuer" by them self. But I am not happy with this solution as it requires some manual action. 

 

So this topic remains open and any further help is warmly welcome.

Certified LabVIEW Architect (CLA)
0 Kudos
Message 7 of 7
(372 Views)