Slow Unit Test Framework

[Yamaeda]

Using DVRs as class references is the core of G#, possibly you can use the same idea just to force the objects to stay in memory.

/Y

[bokorpet]

@tyk007: thanks for the insights! Again, do you know if JKI's test tool can provide coverage statistics? It seems to me not.

@Yamaeda: I'd like to try your proposal but I'm not sure I fully got it. Do you mean augmenting the VI under test with an additional parameter which is a reference (DVR) to the class instance? Can you have a look at the example I attached and be more precise about your proposal?

Regards,

Peter

[tyk007]

---

@Bokor wrote:

@tyk007: thanks for the insights! Again, do you know if JKI's test tool can provide coverage statistics? It seems to me not.

---

I'm failry confident it can't - if you really need this feature then VI Tester is not for you.

[Yamaeda]

Your test project is ofc very fast on my computer so i cant really give any feedback on that, but i have a feeling that it might be an issue of objects loading/unloading fully between each run, in which case it should be improved if you can keep the reference alive. One idea of doing so could be to use a DVR of the object.

/Y

[bokorpet]

@Yamadea: I fail to see how your idea would work. What would force LabVIEW to keep the object in memory after finishing a test case. As you say, the overhead seems to be across test cases. Can you please elaborate on your idea?

@tyk007: thanks!

Peter

[JÞB]

---

@Bokor wrote:

@Yamadea: I fail to see how your idea would work. What would force LabVIEW to keep the object in memory after finishing a test case. (the UTF) As you say, the overhead seems to be across test cases. Can you please elaborate on your idea?

@tyk007: thanks!

Peter

---

Y/ the UTF leaks memory pretty bad the way it is.  Intentionally trying to hold stuff in memeory that is already there seems to be overkill  (Run a p-node "all vi's in memory" after launching and closing a UT config page or running a UT and closing the results)

[Yamaeda]

Maybe that idea doesn't work, but i remember some similar issue with VI server that unloaded everything in between runs, and deselecting automatic cleanup allowed it to stay in memory for faster reruns, maybe that doesn't apply here at all. 🙂

/Y

[bokorpet]

@Yamaeda: I see your point, thanks!

@all: thanks for all inputs!

My conclusion is that no straightforward native solution exists to significantly speed up NI's UTF, at least when used for LVOOP. My frame of reference is 5-6 seconds (with UTF) versus <0.20 seconds (JKI's VI tester as reported by tyk007).

Again, thanks for the discussion.

Regards,

Peter

[bokorpet]

FYI: a new tool called InstaCoverage has been introduced via LabVIEW Tools Network with a specific goal to improve on the run-time efficiency of LabVIEW's Unit Test Framework. Unlike other alternatives InstaCoverage supports code coverage and improves on UTF's run-time by up to two orders of magnitude (e.g., 1h vs 30s in an example commercial LabVIEW project). Here's the link: http://sine.ni.com/nips/cds/view/p/lang/hu/nid/216652