2 The jtr.xml file: a first overview
By means of the jtr.xml file you can configure and assemble a complete JTR test-suite. In this first overview of the jtr.xml configuration file you are going to find all the concepts introduced in the previous section so, before proceeding with this one, be sure you have fully understood all the definitions provided so far.
The content of the jtr.xml file is strictly guided by the XML grammar defined in the jtr.xsd file shipped with every JTR distribution archive. This section introduces this grammar. The following more specific sections will explore all the details of every element introduced here.
The jtr.xml structure
A jtr.xml file starts with the test element which encloses all the elements highlighted in the figure. Let’s now talk about the test element’s attributes.
Test
The test element admits up to five attributes (not all required). First of all a test requires a number of epochs (the runs attribute). runs is the only required attribute for the test element.
The enterprise attribute defines a default enterprise configuration that will be available to every configured runner. The same concept is applied to jms, binding and webservice attributes. All these four attributes are optional and we are going to discuss about them in the following sections in much more detail.
Factories
The factories element, along with its set of factory sub-elements, is used for defining which JTR customizable-modules concrete implementations should be actually used at runtime. As you can see every factory element requires two attributes, namely key and fqn. The key uniquely identifies a JTR customizable-module while the fqn defines its concrete implementation.
This topic is detailed here.
Nodes
One of the most interesting features provided by JTR is its ability to distribute testing among a set of cooperating JTR-enabled nodes.
The optional nodes element serves the purpose of listing a set of available JTR-nodes running in passive mode that will be involved in the testing session by the main active node. Every JTR passive-node is identified by two required attributes, an host and a port.
More details on this interesting feature can be found here.
Runner
With the runner element you can define and configure those software components that will actually perform the test against your target resources and systems.
Every runner element requires:
-
•a runner-fqn sub-element that must define the category (class) the runner instances will belong to
-
•an instance-count, defining the number of instances that must be concurrently active in the same epoch
-
•a parameters-assignment-policy, a keyword identifying a specific strategy that will guide your runners parameterization process
-
•a parameter element, defining all the parameters required by your runner instances
Furthermore every runner specification requires you to define a runs value, the number of times a runner instance will execute in a given epoch potentially with different parameterizations.
The other attributes are all optional and represent default configurations (jee, jms and ws) for every instance of the current category the runner element refers to..
Much more fundamental details covering the runners configuration are provided here.
Enterprise
The enterprise element defines a set of configuration properties used by the JTR-runtime to perform the JNDI lookup of enterprise resources like EJBs. Every enterprise configuration is uniquely identified by the value given to the uniqueName attribute.
A jtr.xml file can host any number of enterprise configurations, meaning either that your test-suites could be simultaneously run against different JEE application servers or that you could switch at your choice the target application server keeping unchanged your runners and simply changing the enterprise configuration they refer to. For more details please go here.
JMS
Just like the enterprise configuration, an optional JMS configuration uniquely identified by a uniqueName, serves the purpose of declaring a set of destinations (administered objects) and JMS connection factories the JTR-runtime will manage on behalf of your runners. This means that you will not have to write a single line of code for accessing JMS connection factories and for retrieving either queues or topics: you can just work on the testing logic you are interested in. Due to the vastitude of the “topic”, go here for details.
Bindings
The optional bindings element lets you define a set of web-services your runners should have access to during the run. The JTR-runtime will perform invocations to your target web-services (every binding represents a web-service) on your behalf leveraging on DII (Dynamic Invocation Interface). This means you will not be asked to code by hand your web-services clients unless you really want/must do it obviously. This topic is covered in much more detail here.
Scripts (only with JTR 5)
By means of the scripts element you can define a set of library and parameterization scripts. Library-scripts, defined by means of the l-script element, are typically used by parameterization scripts and represent some sort of library functions you can use according to your needs. An l-script simply has a body consisting of its definition. Parameterization scripts are characterized by a name, a body, an output and a set of input parameters (if needed). This topic is covered in much mode detail here.
