VI execution within existing application scope

[Jorn_Deruyck]

We have limited experience with teststand, but we want to start using Teststand to perform automated unit tests of class methods.

Ideally we want to perform these tests within the application scope of a running application, iether within the LabVIEW development environment, or when running as a stand alone application.

Ideally we would then only have to link to the Method VI once so that Teststand knows how to interface with its inputs and outputs. And then provide a relative link like "Classname.lvclass:Method.vi" in order for teststand to load the correct function within the application.

Running the methods from within the application scope would allow the methods to access Queues, events, DVR and the likes.

The documentation was not that clear on wether this is possible, or how it should be done. I tried a couple of times by specifying a remote port. But i have the impression that Teststand still tries to run the method from within it's own application scope.

Is it possible to use teststand in this scenario?

Or should i create a wrapper VI that uses "Open Application Reference" to encapsulate the method i want to test?

[Norbert_B · Accepted solution]

If you use the LV DevEnv (Development Environment), it is very easy:

Simply configure the lvproj in the LV steps and then select the VIs from the project.

For 'other' application settings, this is a bit more complex. The suggested way is to compile the application (EXE) with an ActiveX interface (setting in LV build script) and then register that EXE as ActiveX server on the system. After this is done, you can select your application as "Other Executable" from your LV adapter inside TS.

[edjones93]

Hi,

One interesting thing I learned this week is you can call DLL's in your GUI and TestStand will also be able to access the DLL's stored variables (if there are any), when using the TestStand Runtime Engine the GUI and TestStand exist within the same application scope. So if you created a GUI for your tests which loaded your project into memory and then passed these references to TestStand as a deployed system, it should be within the same application scope.

I am however also wondering whether you have heard of the Unit Test Framework? I've included a document on this below:

http://www.ni.com/white-paper/8082/en/

Best regards,

Ed

[Jorn_Deruyck]

We've tried configuring the test steps to run in the project environment.

It works, but due to the large class hierarchies in the project, the Teststand environment becomes slow and unstable.

The current strategy is that we'll be making a client library for the API that the application provides, and use Teststand to interface with the application trough this API.

I didn't give much attention to the unit test framework yet.

I've used it in the past on a few occasions, but i guess i'll revisit that approach to see if it's viable for our current project.

Thanks for the tip!