Leaderboard

Thanks for responding to this! Personally I quite like the VI Tester tool as running unit tests quickly is a great advantage to me. As some feedback I operate in a regulated industry (medical devices); however operating in a regulated industry does not mean that standard architecture and unit testing techniques (such as xUnit) are ignored. They are an obvious advantage and, perhaps compared to other industries, are virtually compulsory for our projects that are not LabVIEW based since they provide a proven mechanism for test infrastructure. And everyone wants to design and test software engineering better and faster - especially those of us in regulated industries . However I concede that the reporting features and code coverage of the UTF is a distinct advantage and adds to our ability to prove sufficient test coverage. I can also understand that it is not desirable to tread on the UTF toes, so to speak. I look forward to hearing more from VI Tester in the future.

Hey Guys, I just want to mention that JKI is committed to making sure that VI Tester works well in LabVIEW. We can't live without it at JKI and it's going to continue to be improved. We've been really busy lately, so that's why there hasn't been a new version pushed out. We see the LV UTF as addressing a totally different market need than VI Tester. As I see it: UTF is great for people who want to show 100% test coverage through its static analysis tools -- NI created it to address the needs of people developing for regulated industries. VI Tester is great for people who want to do better and faster software engineering in LabVIEW -- JKI created it to help test object-oriented (and other) LabVIEW applications using the industry-standard xunit architecture. I can't comment on time-frames, but please stay tuned and don't give up on us. BTW, VIPM 2013 SP1 (one of the areas where we've been busy) was just released (do a check for updates)! We couldn't have done that without VI Tester.

Request deallocation can also be a huge time hit. I've tried it several times on 2D arrays of strings in different situations, and it's... well, not ideal. I ended up writing my string array to a file, and storing an array of mapped integer file offsets. The deallocation problem first showed up with some changes in LV6.1... apparently, it's either not soluble or not a priority.

I also have described similar situations (I think on the NI forums). The main takeaway was that the function is in fact named Request Deallocation, so I guess "Request denied!" is a valid response. Actually I looked at it in some detail at the time and I seem to recall it worked like this: string arrays are stored as an array of handles to the individual strings. RD dutifully returns the memory used by the handle array immediately but the memory used by the individual strings is not freed. I could troll AQ and discuss the LV garbage collector, but there is not one so that memory is not going to be freed in the normal sense. I seem to recall that the memory is reusable by LV so it is not completely lost, but LV can be the RAM roach motel, bytes check in but they don't check out. The quick and dirty solution I have used the few times this has been an issue is to put the offending code into an executable which I can then run dynamically in its own context. Either as a one-shot process or as a daemon. Reclaiming memory was as simple as shutting down the process and restarting.