With the initial implementation of the CLI in JON 2.3 we opened up some of the server side api's to remote access via CLI or straight Java, going forward we should do the following -Extend the remote api to support additional server side apis: e.g. additional areas of the Alerting subsystem, manually add resources -Incorporate tests of the remote api and CLI into our continuous integration testsuite.
Currently, we have a number of CLI test scripts that live under rhq/modules/enterprise/remoting/scripts. The scripts are executed as part of a TestNG test suite that can be run from maven by simply executing mvn test for example. There are a couple classes in the scripts module that programmatically build a TestNG test suite. A separate test is added to the suite for each test script. These tests are integration tests as they do full end-to-end testing between a CLI client and a running server. Most of the tests also expect/require certain resources to be in inventory. Continuing to invest in these tests has a few benefits: * Tests remote APIs * Tests CLI-specific functionality * Provides documentation for CLI usage I will write a up doc on the wiki that provides more technical detail on writing and running CLI tests. I will also outline some of the pros and cons that approach for testing the remote APIs versus other approaches. I spoke with Jeff Weiss about leveraging the work that he and the QE team has done for setting up an rhq server and agent for use during a test run in a hudson build, and it sounds like it is doable.
jsanda - did you ever get to write doco? what is lacking most in documentation?
QE team has taken this to new heights