Index Changes
View Attach (1) Info

N2M Tests

The JBI Test Manager in Netbeans lets you create synchronous request-reply tests. These tests require the binding used to be SOAP over HTTP. that is, they require the HTTP BC to be used. These tests are very useful for testing BPEL-SE as well as testing many other SEs and BCs that can provision services using synchronous request-reply operations. The JBI Test Manager has full support for creating and running such tests using GUI. Once created these tests can be run from the command line. So it is very easy to create and automate these tests.

Some SEs and BCs do not support request-reply operations. For example, IEP SE can only provision and consume services with one-way operations. So we need a mechanism to write tests for such Components. The N2M tests provide this functionality. The N2M tests are driven by sending requests to a SOAP over HTTP endpoint. These requests can be sent to one or more operations (N). The output is sent to one or more files (M). Finally a compariosn is made between the actual output and the expected output, which had previously been configured as part of the test definition. Presently, no GUI support exists to create them, so they need to be created manually. However, they can be run from Netbeans as well as from command line. So it is very easy to automate these tests, just like the synchronous request-reply tests.

Creating a new N2M Test

Lets us take an IEP process as an example. When an IEP process is created it typically has one or more input streams and one or more output streams. The WSDL generated for the IEP process has the following default bindings. A SOAP over HTTP binding and endpoint is created and is shared by all the input streams. Each input stream corresponds to a single operation within the binding. A file binding and endpoint, specfic to File BC, is created for each output stream.

Following are the steps for creating a test

  • Create the IEP project and a Composite Application (Comp App) project.
  • Create all-tests.properties and selected-tests.properties under the Comp App project's test folder. Under the test folder, create another folder corresponding to the test, say TupleBasedAvgCalculator. This folder will serve as a single test. Enter the text "testcases=TupleBasedAvgCalculator" in both all-tests.properties and selected-tests.properties. If you create another test then simply specify it in these files using comma as a separator.
  • Under the TupleBasedAvgCalculator folder, you will create the test files. The best strategy to create a new test is to copy a set of files from an existing test and modify them appropriately. One such set can be downloaded from here. Following describes the files and their purpose.

File N2M.properties - This is the main file that defines the test. Here's a sample 

description=test basic framework
destination=http://localhost:${HttpDefaultPort}/service/iepAttributeBasedWindow_iep
httpwarning=WARNING: SAAJ0014
######### Inputs #########
input.count=1
input.0.action="StreamInput0"
input.0.dataFile=data.txt
input.0.templateFile=template.xml
input.0.batchSize=1
######### Output #########
output.count=1
output.0.actualResultFile=actual.txt
output.0.expectedResultFile=expected.txt
######## Script ###########
scriptFile=script.txt
#featurestatus=progress

destination: The endpoint to which the requests will be sent. This corresponds to the value of "location" attribute in the soap:address element in the WSDL.

input.count: The number of different operations to which requests will be sent. In IEP this corresponds to the number of input streams, in this case 1.

Note: input.0.xxxx refers to properties used for the first operation. If there is a second operation then the properties will be input.1.xxxx.

input.0.action: The SOAP action for first the operation

input.0.templateFile: The file containing a template of the the SOAP message that will be used to send requests for the first operation. Here's a sample (template.xml) 

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
                   xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
                   xmlns:xsd="http://www.w3.org/1999/XMLSchema"
                   xmlns="iepAttributeBasedWindow_iep">
 <SOAP-ENV:Header/>
 <SOAP-ENV:Body>
     <StreamInput0_MsgObj>
       <name>${name.0}</name>
       <value>${value.0}</value>
     </StreamInput0_MsgObj>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>
${name.0} and ${value.0} are tokens that will be replaced using actual values from a file specified using the dataFile property. Note that the tokens are "name" annd "value". The ".0" at the end is required, but has no meaning (?). See below for tips to generate a sample SOAP message.

input.0.dataFile: The dataFile for the first operation. Contains the values that will be used to replace the $ tokens in the templateFile. The first line is a header. Following this, each set of values is specified on a separate line. Comma is used as a separator. Following is a sample (data.txt) 

name,value
ADBE,60.1
ADBE,61.1
ADBE,62.1
ADBE,63.1
ADBE,64.1
ADBE,65.1
ADBE,66.1
ADBE,67.1
ADBE,68.1
ADBE,69.1
ADBE,70.1
ADBE,71.1

output.count: The number of files generated

output.0.actualResultFile: The actual result file that gets generated.

Since we want the output files to be generated in the test folder, we need to specify the file directory appropriately in the WSDL. For example, this test is checked in the open-jbi-components java.net repository at the location CVS/open-jbi-components/driver-tests/iepse/tests/jbi/test/IepAttributeBasedWindow. If you checkout the source under C:/MyEnc/open-jbi-components, the you would specify the file path as C:/MyEnc/open-jbi-components/driver-tests/iepse/tests/jbi/test/IepAttributeBasedWindow.

If you are going to automate the test or even otherwise, you can specify the path as ${ojc-root}/driver-tests/iepse/tests/jbi/test/IepAttributeBasedWindow. Then in File BC you can defined an application variable with name "ojc-root" and specify the value as "C:/MyEnc/open-jbi-components" or whatever is the root for open-jbi-components.

featurestatus: Use this property, if you don't want the test to be run, when the right-click "Test" menu of the Comp App project is selected. The value to set will be "progress". If you want the test to be run then set the value as "done". The default is "done". So if you don't specify the property, it is assumed as "done".

Note: If you change the IEP process definition, then the WSDL file is re-generated. You will lose the changes that you made to the WSDL file. One way to get around this is to ignore the bindings generated by IEP and specify the bindings in CASA. Even in this case, some changes to the IEP file may invalidate the WSDL that you created in CASA and you may have to redo the bindings in CASA.

output.0.expectedResultFile: The expected output in the file represented by output.0.actualResultFile. Initially, you can keep this file blank. After running the test once, the actual output files will be generated. You can review them and if the output is correct, copy the contents into the expected result files.

scriptFile: This is the file which defines how the input will be sent. Here's an example (script.txt) 

wait 60
send input.0 1
send input.0 1
send input.0 1
send input.0 1
send input.0 1
send input.0 1
send input.0 1
send input.0 1
send input.0 1
send input.0 1
send input.0 1
send input.0 1
wait 60

"wait 60" tells the framework to wait 60s before executing the next line. "send input.0 1" tells the framework to send one request to the first operation. So the above script will send 12 requests one after another. The 12 individual commands can be replaced by a single command - "send input.0 12". Note that you can put waits between the individual send commands, if you want to inroduce time lag between sending events. For example, "wait 1".

Generating a sample SOAP message

  • You can import the WDSL in a tool like SOAP UI. SOAP UI will let you create sample requests for your input operation.
  • You can create a dummy test using the JBI Test Manager. Right-click on the test node in your Comp App project and select "New Test Case". Then select the operation and click Finish. This will generate a sample SOAP request in input.xml. Copy this SOAP message in your template file and modify accordingly. Then you can delete the dummy test folder.

Context based configuration for driver tests

While running the tests there could be cases, where one or more of the test parameters need to be changed based on the enviornment the test is running in. For example, when a particular test runs with Oracle database, the output file could have slightly different content than that for other databases. The output itself is valid. This feature allows test creators to specify different configurations based on the context as explained below.

You can guide driver tests to load different configuration files by specifying system property "org.netbeans.modules.compapp.catd.context". The value of property "org.netbeans.modules.compapp.catd.context" must be in the format of a-zA-Z0-9+(_a-zA-Z0-9+)*. That is, the context is defined by a word optionally followed by any pairs of "_" and another word. For example,

  1. oracle
  2. oracle_solaris
  3. db2_nt

Functionality

  1. If system property "org.netbeans.modules.compapp.catd.context" is not defined, then N2M.properties file will be used.
  2. If system property "org.netbeans.modules.compapp.catd.context" has value "word0_..._..wordN" then N2M.properties is loaded first, then N2M_word0.properties, ..., 2M_word0_word1.properties, ... , N2M_word0_.._wordN.properties are loaded in that order if they exists. A property file that is loaded latter has higher priority. That is, if the same property is defined by more than one property files, then the definition from the property file loaded last takes effect.
  3. This is true for all other type of tests (such as Invoke.properties, Concurrent.properties, FaultHandling.properties, Feed.properties, Ftp.properties, Correlation.properties, ConcurrentCorrelation.properties, conc_correlation.properties)

For example, assume org.netbeans.modules.compapp.catd.context has value "oracle_solaris", then the driver test will load N2M.properties(always exists), N2M_oracle.properties(if exists), and N2M_oracle_solaris.properties(if exists) in order.

Assume that N2M.properties has content: 

description=test basic framework
destination=http://localhost:${HttpDefaultPort}/service/iepAttributeBasedWindow_iep
httpwarning=WARNING: SAAJ0014
######### Inputs #########
input.count=1
input.0.action="StreamInput0"
input.0.dataFile=data.txt
input.0.templateFile=template.xml
input.0.batchSize=1
######### Output #########
output.count=1
output.0.actualResultFile=actual.txt
output.0.expectedResultFile=expected.txt
######## Script ###########
scriptFile=script.txt

N2M_oracle.properties has content: 

output.0.expectedResultFile=expectedOracle.txt

and N2M_oracle_solaris does not exist

Then the following properties will be used 

description=test basic framework
destination=http://localhost:${HttpDefaultPort}/service/iepAttributeBasedWindow_iep
httpwarning=WARNING: SAAJ0014
input.count=1
input.0.action="StreamInput0"
input.0.dataFile=data.txt
input.0.templateFile=template.xml
input.0.batchSize=1
output.count=1
output.0.actualResultFile=actual.txt
output.0.expectedResultFile=expectedOracle.txt
scriptFile=script.txt

Setting the property

  • If you are running the tests from Netbeans a simple way to set the property is to specify it in the netbeans.conf file (located under etc folder of your netbeans installation). For example, 
netbeans_default_options=".... -J-Dorg.netbeans.modules.compapp.catd.context=oracle_solaris"
The driver tests will pick up the context value as "oracle_solaris" when running tests from Netbeans.
  • If you are running the test from commandline then you can specify it as part of the JVM arguments. For example,-Dorg.netbeans.modules.compapp.catd.context=oracle_solaris
  • If you want to specify the property at the Composite App level or for a single test, then use the following mechanism.
Modify build.xml: 
    <target name="-check-catd-context">
        <condition property="no.catd.context">
            <not>
                <isset property="org.netbeans.modules.compapp.catd.context"/>
            </not>
        </condition>
    </target>
    <target name="-init-catd" if="no.catd.context">
        <property name="org.netbeans.modules.compapp.catd.context" value=""/>
    </target>
    <target name="pre-init" depends="-check-netbeans-home,-init-caps,-check-catd-context,-init-catd"/>

Modify nbproject/build-impl.xml 

<target name="-do-test-run" ...>
    <junit  ... >
          ....
        <sysproperty key="NetBeansUserDir" value="${netbeans.user}"/>
        <sysproperty key="org.netbeans.modules.compapp.catd.context" value="${org.netbeans.modules.compapp.catd.context}"/>
        <test name="org.netbeans.modules.compapp.catd.ConfiguredTest" haltonfailure="no" todir="${test.results.dir}">
          ....
    </junit>
</target>
and 
<target name="-do-single-test-run" ...>
    <junit  ... >
          ....
        <sysproperty key="NetBeansUserDir" value="${netbeans.user}"/>
        <sysproperty key="org.netbeans.modules.compapp.catd.context" value="${org.netbeans.modules.compapp.catd.context}"/>
        <test name="org.netbeans.modules.compapp.catd.ConfiguredTest" haltonfailure="no" todir="${test.results.dir}">
          ....
    </junit>
</target>

Special wait command for IEP

This is useful when testing TimeBasedAggregator. The TimeBasedAggregator has a size and a start time. The window starts at the start time and is available for the length of time specified by size. When such a test is run using N2M framework, there is no control over when the events will be sent. It is possible that two events event, say with a lag of 1 second to fall in two different windows. To overcome this problem we can use wait-till-next-tick command. This command makes the N2M framework wait till the start of the next window, thus allowing the test writer to send events within the same window.

Syntax

wait-till-next-tick start-time interval-in-milliseconds
  • When start-time is not specified, it is default to 1970-01-01T00:00:00.000+0000
  • Format for start-time is: yyyy-MM-dd'T'HH:mm:ss.SSSZ. Example: 2001-07-04T12:08:56.235-0700
  • Format for interval-in-milliseconds is long integer

Function

"wait-till-next-tick s T" will get the current system time C, find the integer K such that s + (K-1)*T < C <= s + k*T, wait for (s + k*T) - C amount of time, and return.
G'day, Anonymous Guest

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-16) was last changed on 12-Feb-09 17:49 PM, -0800 by Prashant Bhagat