UTF usage and test vectors vs array inputs to VI under test?

[QFang]

I appologize if this is supposed to be clear from online help/documentation, but if so I'm missing it.

What I have: a set of VI's that do vector (1D array) data processing as part of a larger 'algorithm' that is proprietary.  They typically take one or more 1D array inputs and some clustered setup/configuration parameters and output one or more 1D array resulting vectors.

My first look at the UTF made me think that this is exactly what the 'test vector' files is supposed to be for, where I can define my known input and known output (result) vector data and easily pick and choose via the UTF test setup which vector goes to what input and which vector is the expected result... this did not appear to be what happened to me at least. (By default? configurable?), it seems that the vector input files define test permutations, so when I created my input vectors (3 1D arrays of 4000 elements each), the interface pretty much hung itself for minutes as it created what I assume to be a permutation of all possible combinations of these input vectors.. Not what I had in mind.

My second look at using the UTF, I had to create 'setup' and 'teardown' VI's where I manually had to import data from my "known good" sources.  Yeah, I realize I could load it from a file, but either way you slice it, it's fairly manual and repetitive.  The setup and tear-down's are not even created with a script to include the test vi input/output controls.  To top it off, I couldn't find a way to test the outputs in vector/array format either, so in the tear-down I ended up subtracting the test-vi result vector from a constant (known good) vector, getting the absolute values, then getting the min/max and checking if either were nan or out of bounds with a set tolerance e.g. "10^-5", and'ing with any other result checks from the test VI outputs, and passing out a pass/fail boolean that I could check in the UTF.

Maybe this is exactly how I am supposed to deal with my test requirements, or maybe I am totally missing something in the UTF 'framework', but as I have used it so far, it saves very little to no work at all and seems to be 'not so great' way of managing these types of tests?  All the shipping examples seem to be trivial scalar examples and don't really deal with test VI's with array in/out data types? 

I feel I must not be using this framework correctly at all?

[tst]

I don't have experience with the UTF, so these are more general comments.

The first comment is that you seem to have taken the word vector to refer to your 1D arrays, when in fact it refers to the list of possible values to be tested. My understanding is that you already figured that out.

There are also other unit test frameworks, like VI Tester and Caraya. I don't have experience with those either, so I can't comment, but I know some people prefer them.

Lastly, there are a bunch of tutorials and videos on using these different test frameworks and I would suggest going through some of those.

[RobertSalo]

I am trying to automate the creation of the test vectors for my VIs.  In theory this should work, wrote a c# app to create the appropriate input and output values in the  vvect file format.  The only challenge is LabVIEW 2014 UTF does NOT accept the newly programmatically created files.  If the file is created via the UTF dialog, then it works, but the software created one does not.  I did a file compare and ALL the data between a manually create (via dialog working version) and one software create is EXACTLY the same, the only difference I can find is the 'good' file is about 500 bytes bigger.  Does LabVIEW use 'extended' file parameters for test vector validation?  Is there a way to create the test vector files programmatically?

Thanks,

Robert

[QFang]

If your file compare shows they are EXACTLY the same, but the size is 500 bytes different, then you have a problem with your file-compare or your file-size method... You can't have identical files that are not the same size?

When you say they are exactly the same, are you doing a bit-level file comparison? or are you opening it in notepad or something similar and manual?