Running RubberDuckVBA tests through command line or through sub in another module

[dasvin3]

Finding difficult in finding how to run automated tests in Rubberduck through command prompt or through a subroutine in another module and getting the result back in form of text or screenshot of rubberduck testexplorer. I have seen lots of materials related to python testing through command line but not for rubberduckvba.

[daFreeMan]

You're having difficulty finding instructions on how to do this because running Rubberduck tests from the command line not a feature that's available.

Also, you could call the tests in the test modules from code in other modules, just as you would call any method in any module in VBA, there is a test run dialog box designed to make it easy to run the tests.

Considering that testing in this manner was never a though when VBA was designed and that it wasn't built into the last release (VBA7) back in 2010, having the testing infrastructure that does exist now courtesy of RD is pretty impressive (IMHO).

What problem(s) are you trying to solve by running the tests from the command line or from "a subroutine in another module"? Explaining that may give people a better handle on how to direct you than simply providing you with the answer "you can't".

[dasvin3]

Thanks for reply, I am using RD for automated testing of VB scripts in 3d experience platform . As I was able to run the tests by opening platform -open vb editor-click run in test explorer which are manual tasks. The options I can try is 1.Through commandline-not possible according to you 2.Running through an app inside the platform (which is capable to run macro without open editor) but for that I need to access rubberduck test explorer through another module-if this is possible can you help on what is script to access testexplorer and get results back

[Vogel612]

Related other issues:

• 4099

• 803

• 5465

  notably elaborates that headless operation, especially on CI servers is not a supported or intended use scenario for Office Automation

• 5070

This issue is basically a duplicate of 5070 and 4099, since headless office isn't a supported scenario and unit tests require a host application

[dasvin3]

Thanks for reply, so does it mean RD unit tests cannot be run through another sub in module in vb editor , but only by clicking run in host app(here RD test explorer) right.

[Greedquest]

@dasvin3 yes that's basically correct. As @daFreeMan points out, you can call the methods annotated with '@TestMethod manually from VBA, however this wouldn't be hugely useful as the results of the tests end up in the RubberduckAssertClass instance and there's no easy way to extract them out. So all you would be able to find out is if the test raised an uncaught exception, not the pass/fail/inconclusive test result.

So no, you cannot invoke RD tests in any meaningful way without the GUI (clicking run) at the moment.

[dasvin3]

Thanks a lot for the replies

[retailcoder]

Just thinking out loud... perhaps we could conceivably expose a test runner COM type that could orchestrate a test run from a COM client (VBA/VB6 - assuming there's still a way to access the ITypeInfo stuff from there) and provide a way to expose test results? The RD test runner obviously requires RD to be loaded in the VBIDE, which is the main showstopper here (command-line execution wouldn't be loading any IDE addins)... But if there was a class that a test module could reference from the RD library... I think this could be worth exploring.

[Greedquest]

@retailcoder Are you talking about adding a new RubberduckTestRunner COM class that spins up a rubberduck process and automates the GUI stuff? I'm just thinking about test discovery, identifying methods with '@TestMethod requires a complete RD parse correct, it's not metadata contained in the VBx ITypeInfo of a project? This feels a lot like the abandoned RD APi project if it needs to contain a large portion of the RD backend.

Also thinking aloud, maybe another approach could be adding a new COM interface to the [Strict|Permissive]AssertClass which exposes the collected results? The ITypeInfo stuff I did port to VBA/VB6 I think you probably saw, so it should be fairly easy to adapt to invoke the TestInit, TestMethod, ModuleCleanup subs from there, if they can be identified. Maybe rubberduck could even use the '@TestAnnotations to sync with some custom VB attributes that can be picked up in the typeinfo.