Running test from command line

[GiacomoManzoli]

After several attempts i managed to run my tests from the command line using OmnisCLI, but i think that the README.md procedure should be a little bit more detailed. I'm glad to help, but before that, i'm curious if i got it right.

My Omnis environment has in its startup folder:

• omniscli.lbs
• omnistap.lbs
• zHelloTest.lbs (the library that needs to be tested)

Then, inside the zHelloTest.lbs there is an object oCLITest which is just a placeholder, since it only inherits from omnistap.ogOmnisTAPCLI. Furthermore the Startup_Task of the library has to override two methods of omnistap.kgTAPTask:

; --- $construct ---
Do inherited
Do $cinst.$processCLI()

; --- $_getCLIObjectClass ---
Quit method $clib.$objects.oCLITest

By doing this, the inherited omnistap.ogOmnisTAPCLI loads all the tests of the current library, since its $ctask is the Startup_Task of the zHelloTest.lbs.

Did i got it all, or i'm missing something?

Furthermore, i've also find out that if i add the OmnisCI library to the Omnis startup folder, the OmnisTAP command line interface gets hidden by the OmnisCI one. So it's required to have two different Omnis environment, one for OmnisCI and one for OmnisTAP. Maybe a nice feature could be to have the possibility to separate the OmnisCLI logic on multiple libraries!

[barkingfoodog]

Unless you're adding extra CLI actions in your library, you don't need to add the oCLITest object in zHelloTest.lbs. This would eliminate the need to customize $_getCLIObjectClass.

You are correct that you'll need the code to process CLI actions in your Startup_Task. I'll amend the README.md file to include that step.

Currently, OmnisCLI only supports running commands from one library, so you'll want an OmnisCI app that's separate from your app that you're testing.

I can see value in being able to call CLI actions in multiple libraries. I feel you'd need to pass which library you want to use to the CLI arguments. This would help manage conflicting actions that are defined in multiple libraries.

[GiacomoManzoli]

Unless you're adding extra CLI actions in your library, you don't need to add the oCLITest object in zHelloTest.lbs. This would eliminate the need to customize $_getCLIObjectClass.

You are correct that you'll need the code to process CLI actions in your Startup_Task. I'll amend the README.md file to include that step.

Ok!, now i got it, thank! To make it work i used a bit of trial and error, and i didn't notice that only the Startup_task part was required.

Currently, OmnisCLI only supports running commands from one library, so you'll want an OmnisCI app that's separate from your app that you're testing.

I can see value in being able to call CLI actions in multiple libraries. I feel you'd need to pass which library you want to use to the CLI arguments. This would help manage conflicting actions that are defined in multiple libraries.

Or maybe it could solve conflicts by executing all the actions with that particular name. For instance, the omniscli update, should be done by all the libraries that has a $cli_update method.

[barkingfoodog]

Or maybe it could solve conflicts by executing all the actions with that particular name. For instance, the omniscli update, should be done by all the libraries that has a $cli_update method.

Yes, I could see that being useful. If and when you run into the need to have CLI support in multiple libraries, please open an issue over on suransys/omniscli with your use case and we can enhance the tool then.