1 JTR Basic Concepts

Our first step is introducing the basic concepts the JTR Project is based on. All the terms we are going to define in this section will recur in the reminder of the Users’ Guide, so if not already familiar with, you should not skimp this section.


JTR Test

A JTR Test is a test-suite defined by:

  1. •a number of epochs

  2. •a set of customizable JTR-components called Runners

  3. •an optional set of cooperating JTR-nodes

  4. •a set of JTR-runners

  5. •an optional set of enterprise configurations

  6. •an optional set of JMS configurations

  7. •an optional set of Web-Services bindings

  8. •an optional set of library-scripts and parameterization-scripts


Let’ now delve into the details of each of the elements introduced so far.


Epochs

An epoch defines a discrete fraction of time in the time-window required by the whole test-suite. During an epoch each runner will execute all of its duties for a configurable number of times, thus subsequent epochs are used to repeat for the desired number of times the same sequences of tests.


JTR-Components

This advanced configuration concept is covered in a later section. Click here if interested.


JTR-Nodes.

This advanced configuration concept is covered in a later section. Click here if interested.


JTR-Runners

The JTR-runner is the most important user-defined software component (probably the only one) you will work with. A JTR-runner represents a specific testing-logic. This topic is covered in much more detail here.


JTR Standard Parameters

JTR defines a set of well-known and recognized default parameters, namely enterprise, jms, binding, sleepTime. Their meaning is going to be clarified in the next sections.


Enterprise Configurations

Enterprise configurations are required to instruct the JTR-runtime on how to look-up and retrieve EJBs on behalf of user-defined runners. This topic is covered in much more detail here.


JMS Configurations

Just like enterprise configurations, JMS configurations instructs the JTR-runtime how to obtain (on your behalf) every JMS administered object and every JMS factory you might need. This topic is covered in much more detail here.


Web-Services Bindings

Web-services bindings instructs the JTR-runtime how to connect to those web-services you want to test. JTR web-services invocation layer is based on JAX-WS 2.1 and uses DII (Dynamic Invocation Interface) to invoke target web-services. Thus you are not required to write/generate your web-services clients if you do not need them. More details on this topic are provided here.


Library-Scripts (only with JTR 5)

Library-scripts are written by a JTR user with the purpose of consolidating a set of utility functions on which one or more parameterization-scripts can leverage on. JTR supports out of the box library-scripts written using either BeanShell or Groovy, but you can easily write your own JTR-extension for using the scripting language of your choice. More details on this topic are provided here.


Parameterization-Scripts (only with JTR 5)

Parameterization-scripts are scripts that can be used to assign values to runners’ properties. Just like library-scripts, parameterization-scripts can be written using either BeanShell or Groovy, but you can easily adopt the language of love most. More details on this topic are provided here.



Next step: a first look at the jtr.xml file