Difference between revisions of "Testing"

From GreenVulcano Wiki
Jump to: navigation, search
(Description)
(Test output)
 
(3 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
[[File:GVConsoleTesting.jpg|thumb|Testing section]]
 
[[File:GVConsoleTesting.jpg|thumb|Testing section]]
  
Testing Section will facilitate monitoring of the functioning of some components of {{GVESB}}, exploiting the potential of the web. The passage of data and their possible change is in fact visually displayed.
+
Testing Section will facilitate the functional test of some components of {{GVESB}}.
  
 
+
In this area the user can populate the fields of the input objects (as example a [[GVBuffer]] instance) and display the service's execution result. The input object fields, such as the output, changes depending on the requested test.
In this area the user can compile an input object and display output from the execution of the service. The input object, such as the output, changes depending on the requested test.
 
  
 
=={{GVCONSOLE}} Configuration==
 
=={{GVCONSOLE}} Configuration==
  
{{L_GVCONSOLE}} offers the ''Testing'' area for testing the services already configured.  
+
''Testing'' is a Web application that provides a {{GVESB}} service invocation facility, simulating a client request.  
  
The configurable tests in Test Area are related to the following EJBs:
+
In this area you can test the already configured services.
  
 +
The configurable tests in Testing Area are related to the following sub-systems:
 
* '''Core''' to test the direct call to the EJB of GreenVulcano’s Core.
 
* '''Core''' to test the direct call to the EJB of GreenVulcano’s Core.
* '''DTE''' to test the direct call to the EJB of IBXDT.
 
* '''Connector''' to test the direct call to the EJB of connector.
 
* '''HttpOutbound''' for testing {{GVESB}} invocation through HTTP Adapter.
 
* '''HttpInbound''' for testing {{GVESB}} invocation through HTTP Adapter.
 
  
The ''testing'' process is divided into three steps:
+
The ''Testing'' view is divided into three sections:
  
 
* [[#Data input|Data input]]
 
* [[#Data input|Data input]]
* [[#Testing output|Testing output]]
+
* [[#Test output|Test output]]
 
* [[#Exceptions|Exceptions]]
 
* [[#Exceptions|Exceptions]]
  
 
===Data input===
 
===Data input===
 +
[[File:GVConsoleTestingData.jpg|thumb|{{GVCONSOLE}} Testing data]]
 +
For a test that accepts a [[GVBuffer]] input object the display appears as shown in the following figure:
  
 
+
[[GVBuffer]] input Object has default values already set, as ''Id'', but can be changed by the user, or been generated using the "getId" function. In the case of insertion by the user, we recall the normal rules for compiling the ID (unless you want to test the case of incorrect ID insertion):
[[File:GVConsoleTestingData.jpg|thumb|{{GVCONSOLE}} Testing data]]For a test that accepts a GVBuffer input object the display appears as shown in the following figure:
 
 
 
GVBuffer input Object has default values already set as ''Id'' but can be inserted by the user, or been generated using the "getId" function. In the case of insertion by the user, we recall the normal rules for generating the ID (unless you want to test the case of incorrect ID insertion):
 
 
 
 
* Length of 24 hex digits.
 
* Length of 24 hex digits.
 
* Must contain only upper case letters from A to F.
 
* Must contain only upper case letters from A to F.
 
* Not end with 0000.
 
* Not end with 0000.
If user enters incorrect values, the application will however attempt to follow the ''test'' and returns an exception.
+
If user enters incorrect values, the application will however attempt to execute the ''test'' and returns an exception.
  
 +
All the text box for entering input [[GVBuffer]] values are editable.
  
All the text box for entering input GVBuffer values are still editable. These values are:
+
These fields are part of the test environment:
* '''Output File Name:''' name of the file where the test output will be saved;
+
[[File:GVConsoleTestingDataInputFile.jpg|thumb|Test output: file writing]]
* '''Input File Name:''' name of the input file containing the serialized GVBuffer;
+
* '''Output File Name:''' name of the file where the last test output will be saved;
 +
* '''Input File Name:''' name of the file where the last test input will be saved;
 +
[[File:GVConsoleTestingDataIter.jpg|thumb|Iteration number]]
 
* '''Iterator Number:''' number of invocations to be run using the same payload;
 
* '''Iterator Number:''' number of invocations to be run using the same payload;
* '''ID:''' transition unique identifier;
+
In case of iteration of the same test, the [[GVBuffer]] input will be the same but the Id is regenerated for each test.
* '''Service:''' name of the service to be invoked;
+
It is also possible to define a file that contains all the looped test output.
* '''System:''' name of the client system to be simulated;
+
 
* '''ReturnCode:''' numerical return code;
+
These fields are specific for test that accept a [[GVBuffer]] input:
 +
* '''ID:''' transaction unique identifier;
 +
* '''Service:''' name of the Service to be invoked;
 +
* '''System:''' name of the Client System to be simulated;
 +
* '''ReturnCode:''' numeric return code;
 
* '''Character Encoding:''' payload encoding;
 
* '''Character Encoding:''' payload encoding;
* '''Payload:''' data to be sent for testing;
+
* '''Payload:''' input data to be sent;
* '''Properties:''' GVBuffer properties;
+
* '''Properties:''' input GVBuffer properties;
* '''Transaction Mode:''' transition simulation modality;
+
Management of ''properties'' requires the inclusion of multiple name-value pairs with the button ''Properties''.<br/>Moreover, each inserted pair can always be eliminated by clicking on [del] icon.
* '''Forward Name:''' name of the forward to be simulated, if possible.
 
  
 +
* '''Transaction Mode:''' transaction management;
  
Management of ''properties'' requires the inclusion of multiple name-value pairs with the key Properties. Moreover, each inserted pair can always be eliminated by clicking on [del] icon.
+
* '''Forward Name:''' name of the forward to be invoked.
  
 
[[File:GVConsoleTestingDataUpload.jpg|thumb|Upload Data]]
 
[[File:GVConsoleTestingDataUpload.jpg|thumb|Upload Data]]
 
Regarding the ''Payload'', the user has the option to insert the value in the text box or upload a file with the value by the UPLOAD function.
 
Regarding the ''Payload'', the user has the option to insert the value in the text box or upload a file with the value by the UPLOAD function.
  
 +
In case of using the UPLOAD function, the Text Area will contain the selected file content.
  
In case of using the UPLOAD function, the Text Area will contain this file.
+
The UPLOAD function allows the selection of a file and the file content encoding:
 
 
 
 
The UPLOAD function allows the selection of a file and choosing the type of file:
 
 
 
 
* Binary
 
* Binary
 
* US-ASCII
 
* US-ASCII
Line 73: Line 71:
 
* UTF-16
 
* UTF-16
  
 +
If user wants to upload a binary file, the text box of the ''Payload'' field will be replaced by a ''showData'' button that just displays the binary data in the form of hex ''dump''.
  
If user wants to upload a binary file, the text box of the date field will be replaced by a ''showData'' button that just displays the binary data in the form of hex ''dump''.
+
To reset the ''Payload'' field to a text box just click the resetData key.
 
 
To reset the date field to a text box just click the resetData key.
 
 
 
The choice of encoding will change the display of the ''payload'' field. This view, to be correct, requires that you save the file in the right encoding, where it is required the UPLOAD function.
 
 
 
  
For executing the tests, the page offers a number of submit buttons as there are {{GVESB}} possible services to test.  
+
The choice of encoding will change the display of the ''Payload'' field. This view, to be correct, requires that you save the file in the right encoding, where it is required by the UPLOAD function.
  
 +
For executing the tests, the page offers a number of buttons as there are {{GVESB}} standard workflow names to test.
  
[[File:GVConsoleTestingEJBParam.jpg|thumb|Parameters for the connection to EJB]]
+
{|class="note"
 +
|[[File:GVConsoleTestingEJBParam.jpg|thumb|Parameters for the connection to EJB]]
 
Given the specific features of the test to invoke the EJBs, you can set the connection parameters through the ''"Set JNDI Parameters"'' link. This Link proposes a series of useful parameters for an invocation of an EJB and then:
 
Given the specific features of the test to invoke the EJBs, you can set the connection parameters through the ''"Set JNDI Parameters"'' link. This Link proposes a series of useful parameters for an invocation of an EJB and then:
  
 
* JNDI Name: Name of the EJB to be invoked (Required)
 
* JNDI Name: Name of the EJB to be invoked (Required)
* JNDI Factory: Name of the ''application server Factory'' where the EJB was ''deployed''
+
* JNDI Factory: FQN of the application server specific context factory
* Url: URL where the EJB was deployed
+
* Url: Connection factory URL
 
* User: Application server User
 
* User: Application server User
 
* Password: Application server Password
 
* Password: Application server Password
 
 
  
 
The text box will always be editable and propose in the first instance the default values specified in the configuration file:
 
The text box will always be editable and propose in the first instance the default values specified in the configuration file:
 
 
* ''GVSupport.xml''
 
* ''GVSupport.xml''
  
This file will be configurable through the {{GVESB}} interface.
+
This file will be configured through the {{GVESB}} interface.
  
Setting these parameters from the user will remain so for the duration of the test required, except, of course, where the values are ''reset'' to the default ones held at first instance.
+
If the user change these parameters, the values will remain so for the duration of the test and are resetted to the configured ones.
 +
|}
  
 
+
===Test output===
For each input type any validation control is done so any input item is obligatory. It is possible to testing one or configurable more times. In case of iteration of the same test, the [[GVBuffer]] input will be the same but the Id which will be generated for each test.
 
 
 
 
 
[[File:GVConsoleTestingDataIter.jpg|thumb|Iteration number]]
 
The test number to be done can be modified in runtime from the same page, as seen in the following picture:
 
 
 
 
 
 
 
 
 
 
 
 
 
[[File:GVConsoleTestingDataInputFile.jpg|thumb|Test output: file writing]]
 
It is also possible to define a file that contains all the looped test output and if this file is append or not:
 
 
 
 
 
===Testing output===
 
  
 
[[File:GVConsoleTestingGVBufferOutput.jpg|thumb|Single Test Output]]
 
[[File:GVConsoleTestingGVBufferOutput.jpg|thumb|Single Test Output]]
Both for individual tests than for multiple, compared with an invocation, the workbench does not eliminate the input, but still maintains the view to facilitate the comparison with the produced data.
+
Both for single test than iterated test, the application does not eliminate the input, but still maintains the view to facilitate the comparison with the output data.
  
 +
Based on the service expected output format, the application will give the possibility to choose between ''Show Binary'', which presents the binary data in a hexadecimal ''dump'', and ''Show as text'', which presents the data as a string (with encoding to be chosen in a combo box).
  
If the user has sent a binary file, the output will give the possibility to choose between ''Show Binary'', which presents the binary data in a hexadecimal ''dump'', and ''Show as text'', which presents the binary data in a string with decoding to be chosen in a combo box, as shown in the following figure:
 
  
  
Line 131: Line 109:
  
 
[[File:GVConsoleTestingResult.jpg|thumb|Five iteration output]]
 
[[File:GVConsoleTestingResult.jpg|thumb|Five iteration output]]
In the event that has been run the same test for a variable number of times, the output is presented as the following figure:
+
In case of iterated test run, the output is presented as the following figure:
 
 
 
 
  
  
  
  
The ID is generated at run time and will be one for each test. By the link "Output" you can see the result of single test, selecting the encoding type.
+
The ID is generated at run time and will be different for each iteration. By the link "Output" you can see the result of single test, specifying the encoding type.
  
 
===Exceptions===
 
===Exceptions===
  
 
[[File:GVConsoleTestingException.jpg|thumb|Wrong Paradigm Error]]
 
[[File:GVConsoleTestingException.jpg|thumb|Wrong Paradigm Error]]
Each found error will put with the input visualization the exception stack trace.   
+
If the service returns an exception it' visualized with the stack trace.   
 
+
The following picture shows a service invocation failed because the user invoke the wrong Operation:
 
 
The following picture shows a service invocation failed because of followed with the wrong paradigm:
 

Latest revision as of 13:26, 5 March 2012

Description

Testing section

Testing Section will facilitate the functional test of some components of GreenVulcano® ESB.

In this area the user can populate the fields of the input objects (as example a GVBuffer instance) and display the service's execution result. The input object fields, such as the output, changes depending on the requested test.

GV Console Configuration

Testing is a Web application that provides a GreenVulcano® ESB service invocation facility, simulating a client request.

In this area you can test the already configured services.

The configurable tests in Testing Area are related to the following sub-systems:

  • Core to test the direct call to the EJB of GreenVulcano’s Core.

The Testing view is divided into three sections:

Data input

GV Console Testing data

For a test that accepts a GVBuffer input object the display appears as shown in the following figure:

GVBuffer input Object has default values already set, as Id, but can be changed by the user, or been generated using the "getId" function. In the case of insertion by the user, we recall the normal rules for compiling the ID (unless you want to test the case of incorrect ID insertion):

  • Length of 24 hex digits.
  • Must contain only upper case letters from A to F.
  • Not end with 0000.

If user enters incorrect values, the application will however attempt to execute the test and returns an exception.

All the text box for entering input GVBuffer values are editable.

These fields are part of the test environment:

Test output: file writing
  • Output File Name: name of the file where the last test output will be saved;
  • Input File Name: name of the file where the last test input will be saved;
Iteration number
  • Iterator Number: number of invocations to be run using the same payload;

In case of iteration of the same test, the GVBuffer input will be the same but the Id is regenerated for each test. It is also possible to define a file that contains all the looped test output.

These fields are specific for test that accept a GVBuffer input:

  • ID: transaction unique identifier;
  • Service: name of the Service to be invoked;
  • System: name of the Client System to be simulated;
  • ReturnCode: numeric return code;
  • Character Encoding: payload encoding;
  • Payload: input data to be sent;
  • Properties: input GVBuffer properties;

Management of properties requires the inclusion of multiple name-value pairs with the button Properties.
Moreover, each inserted pair can always be eliminated by clicking on [del] icon.

  • Transaction Mode: transaction management;
  • Forward Name: name of the forward to be invoked.
Upload Data

Regarding the Payload, the user has the option to insert the value in the text box or upload a file with the value by the UPLOAD function.

In case of using the UPLOAD function, the Text Area will contain the selected file content.

The UPLOAD function allows the selection of a file and the file content encoding:

  • Binary
  • US-ASCII
  • ISO-8859-1
  • UTF-8
  • UTF-16BE
  • UTF-16LE
  • UTF-16

If user wants to upload a binary file, the text box of the Payload field will be replaced by a showData button that just displays the binary data in the form of hex dump.

To reset the Payload field to a text box just click the resetData key.

The choice of encoding will change the display of the Payload field. This view, to be correct, requires that you save the file in the right encoding, where it is required by the UPLOAD function.

For executing the tests, the page offers a number of buttons as there are GreenVulcano® ESB standard workflow names to test.

Parameters for the connection to EJB

Given the specific features of the test to invoke the EJBs, you can set the connection parameters through the "Set JNDI Parameters" link. This Link proposes a series of useful parameters for an invocation of an EJB and then:

  • JNDI Name: Name of the EJB to be invoked (Required)
  • JNDI Factory: FQN of the application server specific context factory
  • Url: Connection factory URL
  • User: Application server User
  • Password: Application server Password

The text box will always be editable and propose in the first instance the default values specified in the configuration file:

  • GVSupport.xml

This file will be configured through the GreenVulcano® ESB interface.

If the user change these parameters, the values will remain so for the duration of the test and are resetted to the configured ones.

Test output

Single Test Output

Both for single test than iterated test, the application does not eliminate the input, but still maintains the view to facilitate the comparison with the output data.

Based on the service expected output format, the application will give the possibility to choose between Show Binary, which presents the binary data in a hexadecimal dump, and Show as text, which presents the data as a string (with encoding to be chosen in a combo box).



Five iteration output

In case of iterated test run, the output is presented as the following figure:



The ID is generated at run time and will be different for each iteration. By the link "Output" you can see the result of single test, specifying the encoding type.

Exceptions

Wrong Paradigm Error

If the service returns an exception it' visualized with the stack trace. The following picture shows a service invocation failed because the user invoke the wrong Operation: