DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Can I auto generate test vi/code for a new API vi for an existing module ?

Solved!
Go to solution

Fellow wire workers,

 

I love the way that when I create a new module, the test vi is auto created for Main.vi. 

 

Can the same happen for when I create a new vi that is to reside in the (public) API virtual folder ?  (or can code be auto generated to add to the Main.vi tester?)  If so how do I do that ?  (I know about the menu option "Testing Tools\New DQMH Unit Test" , is that the closest I can get ? (it doesn't seem to match the way one is created for Main.vi )

 

I also assume I must manually write any new API vis (as there seems no menu option to do so) - no biggie, just making sure I'm not missing something.

 

thanks,

Peter

Peter
0 Kudos
Message 1 of 7
(1,233 Views)

Hey Peter,

 

let's be very picky about the wording here, just to make sure we're very clear about intent and leave a good place for posterity:

 

The API Tester is generated not for the main.vi but for the whole module. It is supposed to serve as an example of how your module can be used by other code (i.e. from the outside or externally). The API Tester uses the Public API (i.e. the requests found in the /Public API folder) - which is really the only way you should interact with your module.

 

You would then go and create new requests (see https://documentation.dqmh.org/CreatingaNewDQMHEvent.html). Adding requests will create the VI in the public API together with all the internal plumbing that is needed, and it will also add a new button and code to the API Tester so you can immediately test this new request. Btw: Broadcast events will be added to the API Tester, too.

 

If you add a new VI anywhere inside the module's .lvlib manually (i.e. by dragging a VI inside the .lvlib or by right-clicking and selecting New -> VI), nothing else will happen automatically. You have to go through one of the DQMH dialogs (wizards) which you can find in the Tools menu).

 

The DQMH Unit Tests are meant to set you up with the scaffolding for automatically testing your module, again through the Public API.

 

I hope this clarifies things a bit!




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


0 Kudos
Message 2 of 7
(1,207 Views)

Hi Joerg,

 

Thank you very much for your reply.  I apologise if my wording suggested otherwise, and I agree totally with what you wrote.  

Your answer doesn't seem to answer my question though (or perhaps something is not making sense to me).

 

I do not want to import my own vi and just add it to one of the module's API folders,  because I realise that will not generate any testing scaffolding.    I realise that creating a new event (request) WILL auto generate that scaffolding, but my vi (lets call it MyOwn.vi) is not able to be classified as any of the four possible events listed below [1]    instead  MyOwn.vi will just a garden variety vi to achieve stuff (business code) and I intend to place MyOwn.vi as a sub vi of the Main.vi.  But I want MyOwn.vi to have the hooks into it so it can be tested via the module's API tester.

 

Can I use the DQMH scripting menu to create MyOwn.vi, testable via the API tester, and if so how ?

 

[1]

Peter_B_1-1690377884760.png

 

Peter
0 Kudos
Message 3 of 7
(1,196 Views)

Thanks for rephrasing your question, it makes it easier to answer (although the answer will be disappointing for you).

 

In a nutshell, no, there is no way to achieve what you would like. 

 

I'll try to explain why it's not possible, and why that will probably not change in the future: The API Tester is supposed to access the module from the outside (externally). The only way to do this is via requests - they are the only public resources that allow communication with the module from the outside. The API Tester is per definition not supposed to have access to any private resources of the module - just as no other code should have access to private resources.

 

If your VI is not a request but a subVI to the main.vi, it should really not be a public resource but set to private access scope. This in turn means that your VI is not accessible from outside the module, so external resources like the API Tester cannot test it directly.




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


0 Kudos
Message 4 of 7
(1,187 Views)

ok thank you Joerg.

 

If I made MyOwn.vi a public vi then I suppose I could manually add code to test it in the module's API tester.

 

 

Peter
0 Kudos
Message 5 of 7
(1,179 Views)
Solution
Accepted by topic author Peter_B

@Peter_B wrote:

If I made MyOwn.vi a public vi then I suppose I could manually add code to test it in the module's API tester.


Exactly. 

 

Just make sure to think through the implications of making your VI public just for the sake of being able to test it from API Tester. There are better ways (*cough*-*unit-test*-*cough*).




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


0 Kudos
Message 6 of 7
(1,173 Views)

@joerg.hampel wrote:  There are better ways (*cough*-*unit-test*-*cough*).

That sounds like something my team leader would say 😀 , so I'm sure you are right.  I can do both and see on balance which option better serves the needs of the projects (trade off between effort, risk, maintainability, ease-of-use and reward)

 

Peter

Peter
0 Kudos
Message 7 of 7
(1,144 Views)