The JTR Project enables you to extend its behavior quite easily thanks to its modular architecture. As we have already seen in this section, every jtr.xml file starts declaring which concrete implementations of JTR-defined software components must be used at runtime. In this section we are going to explore which pluggability points the JTR Project provides you with, for subsequently showing which interfaces actually need to be implemented for extending the runtime behavior of your test sessions.

JTR’s customizable modules

Here are the keywords identifying all the customizable JTR 4 modules:

1. •IAssignmentPolicyFactory
   

2. •IOutcomeFactory
   

3. •IWsHelperFactory
   

4. •ITestCompletionListener
   

5. •ITestResultDisplayer
   

6. •ITestResultsExporter
   

7. •ITestScriptingEngine
   

8. •ITestStatFunctions
   

For each of these components there are standard default implementations you can leverage on if you need standard behaviors:

1. •jtr.assigner.impl.DefaultAssignmentPolicyFactory
   

2. •jtr.test.impl.DefaultOutcomeFactory
   

3. •jtr.ws.jaxws.JaxWsHelperFactory
   

4. •jtr.test.impl.DefaultTestCompletionListener / HeadlessTestCompletionListener
   

5. •jtr.test.impl.DefaultTestResultDisplayer / HeadlessTestResultDisplayer
   

6. •jtr.test.results.exporters.impl.ExcelExporter
   

7. •jtr.script.impl.BshScriptEngine / GroovyScriptEngine
   

8. •jtr.lang.functions.impl.DefaultStatFunctionsFactory
   

IAssignmentPolicyFactory

This component is responsible for instantiating concrete jtr.assigner.IParamsAssigner instances. The default implementation JTR comes with is capable of recognizing and instantiating two different kinds of IParamAssigners, that is: indexed and cyclic. If neither of theses two assignment strategies fits with your needs, it is possible for you to plug-in your own implementation.

This can be achieved implementing your own versions of the following interfaces:

1. •jtr.assigner.IAssignmentPolicyFactory: your implementation must extend the default one
   

2. •jtr.assigner.IAssignmentPolicy
   

3. •jtr.assigner.IParamsAssigner: you could inherit from jtr.assigner.impl.AbstractParamsAssigner
   

For more information on the methods that must be implemented, please refer to the Javadoc.

IOutcomeFactory

This component is in charge of providing concrete instances implementing either the jtr.test.IOutcome interface or of any of its possible user-defined sub-interfaces. For example you could find useful customizing this component if you wanted your runners’ outcomes carry more information than they do in their default version.

In order to do this, you will need to provide your own implementations of the following interfaces:

1. •jtr.test.IOutcomeFactory
   

2. •jtr.test.IOutcome
   

For more information on the methods that must be implemented, please refer to the Javadoc.

IWsHelperFactory

This keyword identifies the concrete component in charge of providing support in web-services related tasks, thus support to webservices-enabled runners. By default JTR 4 comes with two implementations of this component, one which is based on JAX-WS 2.1 and the other (deprecated) based on WSIF 2.0.

If you wanted to drastically change the underlying webservices-engine you could provide your own implementations of the following interfaces:

1. •jtr.ws.IWsHelperFactory
   

2. •jtr.ws.IWsHelper
   

For more information on the methods that must be implemented, please refer to the Javadoc.

ITestCompletionListener

The component identified by this keyword is responsible of the following duties:

1. •receiving test-completion notifications from both local and remote nodes (active and passive nodes)
   

2. •providing the user with a feedback about test evolution
   

Another not compulsory task is the forwarding of received test-completion notifications to another customizable component in charge of showing them all to the user.

In order to change this component you simply have to provide your own implementation of the jtr.test.ITestCompletionListener interface.

For more information on the methods that must be implemented, please refer to the Javadoc.

ITestResultDisplayer

Typically an implementation of the jtr.test.ITestCompletionListener interface forwards the results it receives to a component in charge of showing them to the end user (for example). Concrete components in charge of performing this task must implement the jtr.test.ITestResultDisplayer interface.

For more information on the methods that must be implemented, please refer to the Javadoc.

ITestResultsExporter

This keyword identifies those components in charge of exporting JTR-native data-structure used to represent test results to other formats. The default implementation the JTR Project comes with is meant for performing this task having as target format the Excel format. In order to override this behavior, please provide your own implementation of the jtr.test.ITestResultsExporter interface.

For more information on the methods that must be implemented, please refer to the Javadoc.

Next step: useful testing tips