This section explains how the functionality of the component can be tested. A very simple way to test the component is to create a flow with the component and run the flow to check if the desired results are obtained. At times, the result may not be the desired one, not due to a fault in the component logic but for external reasons. Therefore, Fiorano provides an exclusive option to test synchronous component logic.

Testing Synchronous Components

Synchronous components can be tested:

  • During configuration by using the Test button in the Configuration Property Sheet (CPS)
  • Using JUnit Test Cases

Testing in Configuration Property Sheet (CPS)

For all synchronous components, the CPS contains a Test button in the Managed Connection Factory (MCF) panel (for connection-based components as in the figure below) as well as in the Interaction Configurations panel.

Testing the Connection

To test the connection that the component makes with the underlying EIS, specify the connection details in the Managed Connection Factory panel and click the Test button.


Figure 1: Managed Connection Factory (MCF) panel showing the connection details and Test button

A dialog box is displayed showing the result of the operation (connecting to EIS) performed.  A text/XML result shows the connection details of the EIS to which the component connects.


Figure 2: The result of the test on the MCF. The connection to the database is successfully established.

A trace of error/exception occurs while the component fails while trying to connect the MCF.


Figure 3: Exception when the test in the MCF panel fails

Testing the Business Logic

The Interaction Configurations panel in the CPS contains details defining the business logic that the component executes. Testing can be performed using JMS Headers and without using JMS Headers in the Input Message. Both are explained in the sections below.

Testing Input Message without JMS Headers

The business logic of the component can be tested using the Test button in this panel.


Figure 4: Interaction Configurations panel showing the test button

The Test dialog box gives the option of invoking the component with sample input, which is pushed onto the input port of the component during runtime. The component processes the input message and displays the output message, which goes to the output port of the component during runtime.


Figure 5: Test dialog box to test the component's business logic, showing input message details

The Input Message tab allows specifying the input message and shows the details of the input message. To view the input port schema, click the Input XSD button. The dialog boxes below shows the input port schema details.


Figure 6: Port schema (text view)


Figure 7: Port schema (tree view)


Figure 8: External XSDs for the port schema

To test the component, click the Execute button (Figure 5). The output is shown in the Output Message tab (Figure 9). To view the output port schema, click the Output XSD button. A dialog box similar to the dialog box of the input port schema (Figure 6 to Figure 8) is displayed showing the output port schema details. To validate the output message against the output port schema, click Validate.


Figure 9: Result of the test operation

Testing Input Message with JMS Headers

The Interaction configurations of the BC components enables adding JMS-Headers to the output message for testing.

In the Interaction Configurations panel, click the JavaScript ellipses button. In the JavaScript editor, provide the testing script.


Figure 10: Providing Javascript in the JavaScript editor

The Input Properties tab helps to add the JMS message properties for the input message during the CPS time testing.

Click the Test button to open the Test Interaction Specifications dialog box. Click Add to add the JMS message properties for the input message and then click Execute to test the business logic. The result appears in the Output Message tab.


Figure 11: Adding Input properties

The Output Properties tab displays all the JMS message properties which were added in the Input Properties tab and which are present in the output message after processing.


Figure 12: Values generated in the Output Properties pane

Testing using JUnit test cases

Fiorano provides a JUnit test framework to test the logic of the component created. A JUnit Test Case can perform test operations in the Managed Connection Factory panel as well as in the Interaction Configurations panel.

Configuring a JUnit test case

To write a JUnit Test Case, create the test hierarchy shown in the figure below.


Figure 13: Structure for JUnit test cases for the component

The test.properties file is a properties file that contains the list of paths to Test Cases relative to the tests directory. The entry in the test.properties file for a structured output (Figure 10) looks as below:


Figure 14: Entry in test.properties, listing all the test cases

Each test should contain a file 'tc.properties' that contains the configuration of the test case. The configuration of a test case includes configuration of the component. The input message text that has to be passed to the component and expected output the component should return. The list of properties that can be specified is shown in the table below.

PropertyDescriptionDefault

bcConfig

Configuration XML of the component saved using configureBC.bat utility.

bcConfig.xml

configuredUsingStudio

Indicates whether the configuration is given as mcf and jca files or as configuration XML.

  • true – configuration is specified as mcf and jca files.
  • false – configuration is specified as a configuration XML from the configureBC.bat utility.

true

compareInteractionOutput

Specifies whether or not the output of the component should be compared with jca.output

  • true – compare
  • false – do not compare

true

connectionLess

Indication to test the framework–whether or not a test for connection has to be performed.

  • true – component is connection-based and connection test has to be performed.
  • false – component does not create a connection and the test for connection need not be performed.

    Icon

    If false, then mcf.output property should be specified.

false

inputContentType

The type of input message text. Values from:

  • TEXT – plain text
  • XML – XML message
  • BYTES – Binary content

XML

inputPropsFile

Location pointing to a file containing message properties that should be passed to the component.

Example: COMPLETED=true in case of FileWriter.

inputProps.properties

Jca

jca file containing the interaction configurations.

bc.jca

jca.exception

File containing the expected exception for a negative test case.

interactionException.xml

jca.input

File containing the input message content that should be used to test the component.

interactionInput.xml

jca.output

File containing the expected output from the component..

interactionOutput.xml

Mcf

mcf file containing the connection configurations.

bc.mcf

mcf.output

File containing the expected result of the connection test.

mcfOutput.xml

mcf.exception

File containing the expected exception message for a negative test case.

mcfException.xml

negativeTest

  • true – if the test case is configured for a negative test (compares output with jca.exception and mcf.exception.
  • false – if the test case is configured for a positive test (compares output with mcf.output and jca.output).

false

xmlDiffClass

Custom comparison class for comparing outputs of interaction.

Usage:
Implement a class extending org.custommonkey.xmlunit.Diff with a constructor to take two String arguments 'actualOutput' and 'expectedOutput'.

Add it to the class path for tests by specifying it in tests.lib path such as structure, which can be over-ridden in components.

none

A typical tc.properties file contents are shown in the figure below.


Figure 15: Sample tc.properties

Icon

For components and component configurations which might return multiple outputs for a single input, the expected output files should be suffixed with the sequence number before the extension.

Example: If the entry in the tc.properties file is output.xml, then the expected outputs should be specified in files output1.xml, output2.xml and output3.xml for configurations returning 3 output messages.

Executing a JUnit test case

To run/execute the JUnit test case, execute ant runtests from the component' folder. A folder named 'testLogs' is automatically created in the component folder. Logs of the individual test cases is present in tests folder which is under testLogs. The directory structure of testLogs folder is shown in the figure below.


Figure 16: Directory structure of the testLogs containing the results of tests

Classes specific to the component can be added to the classpath of the tests execution by adding them in the tests.lib path in the build.xml file of the component as shown in the figure below.

Icon
  • To perform tasks before tests start, add a target 'testspreprocess' to the component build.xml (see the figure below).
  • To perform tasks after the tests end, add a target 'runtests' to the component build.xml.
Icon

Both 'testspreprocess' and 'runtests' target should depend on the corresponding targets in the common.xml.

The figure below shows the content of a sample build file containing necessary entries to start the FMQ server before the test cases begin and to shutdown the FMQ server after the test cases end.


Figure 17: Sample build.xml containing necessary entries for tests.lib, testspreprocess and runtests

Testing Asynchronous Components

Unlike synchronous components, the asynchronous components cannot be tested during the configuration time, unless the required functionality is specifically added. However, Fiorano provides a testing framework for testing asynchronous components as well. JUnit testing of asynchronous components is similar to JUnit testing of  the synchronous component

Configuring a JUnit test case

To write a JUnit test case, create the test hierarchy as shown in the figure below.


Figure 18: Structure for JUnit test cases for the component

The test.properties file is a properties file that contains the list of paths to test cases relative to the tests directory. The entry in test.properties for structure shown in the figure above is shown below: 


Figure 19: entry in test.properties listing all test cases

Each test should contain a config.xml file.

This file contains the configuration of the component. The configuration can be obtained by performing the below:

  1. Create an Event Process
  2. Drag and drop the asynchronous component to be tested
  3. Configure the component
  4. Save the Event Process

Extract the configuration from the application's XMLile. Copy the configuration to the config.xml and save the config.xml file. To extract the configuration from the application's file:

  1. Open the application XML file located at %FIORANO_HOME%\esb\fes\ repository\applications\<APPLICATION_NAME>
  2. In the XML file under the /Application/ServiceInstances node, look for the ServiceInstance node of the required component
  3. Under the ServiceInstance node from ./RuntimeArguments/ UserDefinedPropertySheet node, copy the CDATA section and save it to the config.xml file

command_line_arguments.txt

This file consists all command line arguments to be passed to the component during the launch of the component. A typical command_line_arguments.txt is shown below.


Figure 20: The command_line_arguments.txt for an asynchronous component

The tc.properties file contains the configuration of the test case. The configuration of a test case includes input ports and output ports that have to be created as well as the location of the files containing input messages to be passed and output messages to be compared. The list of properties that can be specified is shown in the table below.

PropertyDescription

inputPortNames

Comma separated values of the input port names that the component has for this configuration.

outputPortNames

Comma separated values of the output port names that the component has for this configuration.

otherTopicNames

Any other JMS destinations that have to be created for the execution of the component.

inputFiles

A list of files, each containing a single message to be sent on the input port. Specify a comma-separated list of values to be sent on to each of the input ports specified in the inputPortNames list.
Example:
If a component has two input ports where message in input1.txt is to be sent on to the IN_PORT1 and message in input2.txt is to be sent on to the IN_PORT2, then entries should be:

If multiple inputs have to be sent to the input port, then specify a colon-separated list in each of the comma-separated value.

Example:
If messages from input11.txt and input 12.txt have to be sent to IN_PORT1 and messages from output21.txt, output22.txt and output23.txt have to be sent to IN_PORT2, then specifications to be used are:

outputFiles

A list of files which have to be populated with the output messages when the test is executed. This should be a comma-separated list, mapping to a corresponding output port in the outputPortsNames list. These files can be empty or non-existent.

expectedOutputFiles

A list of files, each containing an expected output message that should be received on the output ports of the component. This should be a comma-separated list mapping to a corresponding output port in outputPortsNames list.

A typical tc.properties file is shown in the figure below.


Figure 21: Sample tc.properties

Executing a JUnit test case

Prior to executing a test case, an Event Process with the newly created custom component should be launched with the same details given in the command_line_arguments.txt file as explained above. To run/execute the JUnit test case, execute ant runtests from the component folder. A folder named testLogs is automatically created in the component folder. The directory structure of the testLogs folder is as below.


Figure 22: Directory structure of the testLogs containing the results of the tests

Classes specific to the component can be added to the classpath of the tests execution by adding them in the tests.lib path in the build.xml file of the component as shown in the figure below.

Icon
  • To perform tasks before tests start, add a target 'testspreprocess' to the component build.xml (see the figure below).
  • To perform tasks after the tests end, add a target 'runtests' to the component build.xml.
Icon

Both tests 'preprocess' and 'runtests' target should depend on the corresponding targets in the common.xml.

The figure below shows the content of a sample build file containing entries necessary to start the FMQ server before the test cases begin and to shutdown the FMQ server after the test cases end.


Figure 23: A sample build.xml containing necessary entries for tests.lib, testspreprocess and runtests

Adaptavist ThemeBuilder EngineAtlassian Confluence