AST Unit Tester

[ASTDan]

Hello,

 

I developed a simple and quick unit tester.  

 

My reason for developing this was NI's unit test framework is way to slow.  

 

Here is the download on the NI community site

 

https://decibel.ni.com/content/groups/ast-unit-tester?view=overview

 

I also included a VI Package file

 

Any feedback would be appreciated

 

Thanks

automated_software_technology_lib_ast_unit_tester-1.0.0.30.vip

[hooovahh]

I haven't used the NI one, but the little amount I played around with the JKI Caraya unit tester, it seemed pretty slick.  Have you used that unit test software?  And did you also find it to be slow?

[ASTDan]

I have used JKI unit tester.  I found that to be slow as well.  I looked at JKI Caraya.  I was working on mine at the time...

 

I had an idea on how I wanted to do Unit Tests and I made a tool for it.  So far it is working well for me.

 

I was wondering if there was anyone else out there who would benefit from my cludgy way of thinking.

[ShaunR]

The issue I have with most unit test frameworks is that they effectively double, triple or even quadruple your code base with non-reusable, disposable code - increasing effort and cost substantially and often for minimal gain - more code = more bugs. This means you are debugging a lot of code that isn't required for delivery; for a perceived  peace of mind for regression testing. I skeptical that this is a good trade-off.

 

I couldn't install the VIP since it is packaged with VIPM 2014+ (I'm still livid at JKI for that). I did, however, extract the goodness and look at it piecemeal but couldn't actually run it because of all the dependencies that were missing.So if I've missed some aspects, I will apologise ahead of time

 

It looks like early days as you find your way through. Some things you might want to look at......

 

1. Instead of creating a VI for every test with a pass/fail which you then scour for that indicator  Look at "hooking" the actual VIs front panel controls' (there is an example on here I posted a long, long time ago)  and comparing against expected values and limits. This will move the "pass/fail" into a single test harness VI, much like a plug-in loader, and for non iterative tests-will give you results without using a template or writing test specific code..

 

2. Consider making the "Run Unit Tests" a stand-alone module. This will enable you to dynamically call it from multiple instances to run tests in parallel, if you so desire.

 

3. Think about adding a TCPIP interface later on so that you can interact with other programs like Test Stand (forget all that crappy special Test Stand Variable malarkey ). This means that your test interface is just one of a number of interfaces that you can bolt on to be the front end and doesn't even limit you to LabVIEW. (how about a web browser ? ) With a little bit of thought, this can be extended later into a messaging API to cater for iteration, waiting and command/response behaviour. This, along with #2 is also the gateway to test scripting (think about how I may have tested the Hal Demo as both a system and as individual services).

 

Edited: 'cos I can

Edited March 30, 2016 by ShaunR

[ASTDan]

Thanks for the feedback!

 

I too have found maintaining a test library to be cumbersome.  However I have to test my code somehow...  Why not try to automate the tests I have created anyway...  That was the idea in creating the unit tester.

 

1. Instead of creating a VI for every test with a pass/fail which you then scour for that indicator  Look at "hooking" the actual VIs front panel controls' (there is an example on here I posted a long, long time ago)  and comparing against expected values and limits. This will move the "pass/fail" into a single test harness VI, much like a plug-in loader, and for non iterative tests-will give you results without using a template or writing test specific code..

 

That is kind of like the NI unit tester.  I tried that.  I found it to be slow.  When I am developing I build some code that tests the VI's as I code along.  My unit tester is just an automated way of leveraging tests I have already created.  I guess this is a personal preference on how people work, or it just exposes the clunky way I work...

 

2. Consider making the "Run Unit Tests" a stand-alone module. This will enable you to dynamically call it from multiple instances to run tests in parallel, if you so desire.

 

Not a bad idea

 

3. Think about adding a TCPIP interface later 

 

Interesting

 

Again thanks for the feedback

[Tim_S]

The issue I have with most unit test frameworks is that they effectively double, triple or even quadruple your code base with non-reusable, disposable code - increasing effort and cost substantially and often for minimal gain - more code = more bugs. This means you are debugging a lot of code that isn't required for delivery; for a perceived  peace of mind for regression testing. I skeptical that this is a good trade-off.

 

I recently had a... let's call it a a conversation... with a customer who was insistent the system would work perfectly for 10 years. The only way I know to do this is to provide double-redundant systems and perform a level of testing that takes months to perform. None of my customers are going to want the extra price tag that goes along with the redundancy or testing. If my customer base was from, oh, medical or nuclear power... now that's a different story; then I would be contractually required to perform tests on all sorts of specifications (the IEEE ones on software are good for insomnia) and there would be a budget and a reason to do so.