Preface: I haven't used TestComplete at all for anything, so please excuse any misunderstandings I might have about how it operates and interacts with applications.
To the meat of this discussion though:
A customer sent me a very intriguing email today, saying that they had an engineer trying to use TestComplete to create UI-based unit tests against a LabVIEW application. Long-story short, they couldn't even get the majority of UI elements to appear at all. Knowing some details about LabVIEW, I can say I'm completely unsurprised. However, this spurred an interesting line of thought: How, if even possible with LabVIEW in its current state, would this work? UI testing always seems to be the one 'thing' that is difficult to setup in LabVIEW. You can do a bunch of VI scripting to make it happen, but the overhead on that is completely silly to get it to operate as intended, at least with the current tools available. Further, would User Interface testing even fall under the umbrella of a 'unit'? I could see good arguments for either side of that (System vs. Unit).
Anyways, I was hoping to get some thoughts on how UI fits the scheme of testing for the development and verification of LabVIEW applications. TestComplete or not, I'm curious to see how the community feels about this subject. I'm open to any thoughts on the subject!
Well, the website clearly states the list of supported technologies, and LabVIEW isn't on the list - not suprising, as you say.
I would say that UI testing isn't unit testing but rather usability testing / acceptance testing. have you seen this? https://decibel.ni.com/content/message/84695#84695
I have never done it, but from what I had investigated at one point, the way to use TestComplete with LabVIEW would involve building a LabVIEW DLL and call into it from one of the scripting languages supported by TestComplete and use those to make use of LabVIEW functions.
It seemed way too complicated.
I agree with tyk007, UI testing is not unit testing and I do recommend following that thread, there were some other tools discussed there, https://decibel.ni.com/content/message/84695#84695
What we have done for projects that use the DQMH is to use the API tester as a way of testing "macro operations", so for example, if an end user will be able to click a series of 3 buttons, we can use the API tester to call those three functions back to back (this will get to simulate the series of operations at a speed faster than even the end user would get) and then we can use VI Server to get the status of the screen. The reach of this kind of testing is limited, because it will not be able to test all of the interlocks and pop ups that might get generated in the application. We do as much as possible this way, the rest is addressed by detailed test plans that have someone going through the end user steps at integration testing time.
While it's true that UI testing isn't Unit Testing, it can be a useful tool to help with unit testing. Most of the time, when we think of unit boundaries, we think of the connector pane - it's where we access inputs and outputs to a unit. For better or worse, LabVIEW has a hard link between the connector pane and the user interface (if you want something on the connector pane, it must be on the front panel too), so unit test vectors typically go through the user interface in a way.
I'm not advocating for replacing connector-pane unit testing with user interface-based testing, far from it, but it's important to understand that they are not diametrically opposed concepts. At times, it's okay to use user interface testing to augment unit tests.