does anybody know if the Unit Test Framework considers inlined subVIs recursively when measuring coverage?
Consider following example:
if (false) return -1;
else return 0;
Obviously, there is no test for g() with 100% (branch) coverage, and any test for f() achieves 100%.
My question is: given a test for f(), does UTF give a different coverage if I set g() to be inlined (<100%) or not (100%)?
Solved! Go to Solution.
no, the subVI cannot be analyzed for code coverage if set to inline.
Point is, that inlining requires the option "Allow Debugging" to be disabled (yeah, i hate double-negation!), but if debugging is not allowed, code coverage will result in 0%.
"You must allow debugging for each VI under test in order to measure code coverage. If the VI properties of a VI under test do not have a checkmark in the Allow debugging checkbox, the code coverage result always will be zero."
Thanks Norbert! Once again 🙂
It's a pity though that things work like this. I see that certain debugging tasks are impossible (or make no sense) with inlining (such as determining the calling sequence) but code coverage is not really debugging (or at least a very special aspect of it), is it? Anyway, this is how things are at the moment.
the reaon for this is that the VI (debugging disabled) isn't aware of its block diagram during execution... or, to turn it around: When debugging is enabled, execution and block diagram are "linked". For coverage analysis, that "link" is necessary as you have to compare "executed subdiagrams vs. all available subdiagrams in the source code".
I see that, but what does it have to do with inlining?
I mean, LabVIEW could inline a subVI (compiler instruction) and use the block diagram for coverage.