Hey Eli - first of all, thanks to NI for adding UTF and Desktop Execution TraceTool Kit to LabVIEW Core.
Not sure if there already is a way to do this - if there is - I have not found it. In order to simplify test cases, it is very convenient to change the contents of a wire. For example, to force an error case on return from a sub-vi. Creating stubs is painful and clunky. Modifying the code, or complicating the code (e.g. with diagram disable structures) to force an error on the wire - well - that sort of defeats the purpose of a Test Framework.What I was hoping to find was an 'active' probe (as opposed to 'passive') that I could then place on a wire as part of a test case. My active probe would allow me to over-ride values in the wire. End result? I define my test case - place active probes on whatever wires I choose, define the values that should be placed on the wires, define expected outputs, and done! No changes to the underlying code.
In addition to making UTF much more efficient, this would be a very useful debugging tool. Add it to conditional probes, and now we are talking power.
Here's hoping there is a way to do this already.
Are there any CARs or known issues with running Unit Tests on VIs with Formula Nodes? We're running LV201SP1, and we pretty consistently see hard crashes when we try to run any tests on VIs with large (say, >100 lines) formula nodes.
[We've actually seen a lot of bizarre behavior with bigger formula nodes--we've found a pretty effective way to force quit LabVIEW is to attempt to probe an input/output wire in a VI containing a large formula node.]
I am also bothered by long load times, but I also have a problem described here http://forums.ni.com/t5/LabVIEW/Source-distribution-unit-test-dependency-problem/m-p/2246000#M713189 and still waiting for an answer.
Do you have VIs that can reproduce UTF crash? Do you mind to share it?
[-] I just wasted an hour trying to generate an *.lvtest file for a VI, but it simply will not correctly access the controls and indicators on the VI front panel (there are three--a string control, a string array indicator, and an error out).
Could you be specific about the steps about this?
I would like to see the character restrictions on control labels removed. Anything that is allowed in LabVIEW should be accepted by the Unit Test Framework.
It would be nice if the Run Tests from File.vi could avoid opening the "Save Changes?" dialog upon completion.
As part of our continuous integration system, we have an automated system that will run all unit tests prior to our nightly builds. It sucks that sometimes the process hangs up because Run Tests from File.vi triggered some recompiles and the "Save" dialog is waiting on user input. I presume that happens when it closes the VI references for the files under test.
Maybe there could be an option to bypass that step--just force close (effectively do the "Don't Save - All" option) the VI once the test is complete--for when we run unit tests automatically. It shouldn't require any direct user interaction.
Is this what you mentioned "crash" in the previous note?
For this problem that you encountered, the problem might be that you are loading some VIs which need to be compile during run time. As you know when LabVIEW starts to compile the VI, the code has be changed then LabVIEW requires to make the decision of "save" or not. Could you please do a mass compile for the files that you want to test before using the Run Tests from File.vi?
UTF allows characters for control labels that LabVIEW allow. What restrictions do you see?