JBoss Unit design (ant and maven support)

[bdaw]

I added a wiki page about JBoss Unit design. Currently its only about ant / maven support. Feel free to comment:

http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossUnitDesign

[julien1]

I have started to add a jpda option (very incomplete but works), for now it is

<tests jpda="true" ...>...</>

which set remoting debugging on port 8000, it works for now, it will need a more serious configuration and probably at the jboss-unit level rather.

[julien1]

We need the capability to be able to set parameters on Main that will be used as global parameters (overriden naturally by the jboss-unit.xml values).

From ant we need to be able to set them from the jboss-unit task, in order to pass an ant property to a test execution such as:

<jboss-unit>
 <tests ...>
 <parameter name="foo" value="${foo_value}"/>
 </tests>
</jboss-unit>

<jboss-unit>
 <parameter name="foo" value="${foo_value}"/>
</jboss-unit>

from the command line we would have the matching equivalent.

[julien1]

I am going to add the following for the test driver:

public interface DriverContext
{
 String getProperty(String name);
}

and on the TestDriver interface the following methods:

void init(DriverContext context);
void destroy();

I need to have proper demarcation of the life cycle of a test driver, which is needed in various places. I also need test driver configuration which is different from parameters. A test driver configuration is something like the local directory that would contain archives to deploy, or the initial node id in a distributed test.

Those would be added to the jboss-unit.xsd as well as runtime switches.

[julien1]

I ended up introducing a TestRunnerContext instead of the TestFilter for running tests:

public interface TestRunnerContext
{
 TestFilter getFilter();
 Map<String,String> getProperties();
}

Properties are propagated to test drivers so they can use it for configuration during the life cycle phase I introduced (which is a good idea imho).

I plan to move runner listener support to TestRunnerContext instead of making it part of the TestRunner interface, so basically remove the add/remove listener and rather have a fireEvent(TestRunnerEvent) on the TestRunnerContext which will provide more flexiblity.

[julien1]

I think we should move in Ant the section and scope it per . Indeed, one invocation of the command line will put all the reports and having several using the same file on the disk will likely produce overwrites.