Description of problem:
These tests will involve three components - a running server, a running agent, and a test driver. Assume that each runs in its own separate process. The test driver will have two main responsibilities. It will coordinate work flows like starting server and agent, and it will perform verification. Let me illustrate with an example.

Test Scenario: 
Resource exist in server inventory with drift definitions. Agent is started with the --purgedata option.

Test Driver:
* Start RHQ server
* When server is initialized, start agent with --purgedata
* Wait for for agent to initialize and complete inventory sync
* Verify that resource along with drift definitions exist in agent's inventory

There are some subtle details I left out here like how the test will know when the server has initialized or how it will know when the inventory sync has finished. Getting this infrastructure set up will require a good deal of work; however, it provides us with broad test coverage not possible with unit tests. This could also lay the foundation for other integration tests for things like provisioning.

In order for the test driver to orchestrate work flows, we will likely have to do some refactoring to provide test hooks. First, consider the simpler case where everything is in-process and we need to know when the RHQ server is initialized. At the end of StartupServlet.init method, we might want to fire off some sort of event to indicate that server initialization has completed. The test driver would simply listen for that event. Since the test driver will be running in its own separate process, that event listener (i.e., test hook) will need to forward that event to the test driver, possibly via REST or some form of RPC. We will need take a similar approach on the agent.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info: