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.  
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.
 
 
 
Next step: a first look at the jtr.xml file