Testing - Revision history

Anonymous: /* Test output */

2012-03-05T13:26:44Z

‎Test output

G.dimaio at 11:38, 19 February 2012

2012-02-19T11:38:49Z

Show changes

G.dimaio at 10:51, 19 February 2012

2012-02-19T10:51:31Z

Anonymous: /* {{GVCONSOLE}} Configuration */

2012-02-16T17:41:48Z

‎{{GVCONSOLE}} Configuration

Anonymous: /* Description */

2012-02-16T17:40:25Z

‎Description

Anonymous: /* {{GVCONSOLE}} Configuration */

2012-02-16T17:38:36Z

‎{{GVCONSOLE}} Configuration

Anonymous: /* Testing output */

2012-02-16T17:27:27Z

‎Testing output

Anonymous: /* Testing output */

2012-02-16T17:26:48Z

‎Testing output

Anonymous at 17:26, 16 February 2012

2012-02-16T17:26:11Z

Anonymous: /* {{GVCONSOLE}} Configuration */

2012-02-16T17:24:14Z

‎{{GVCONSOLE}} Configuration

@@ Line 99: / Line 99: @@
 ===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).
 [[File:GVConsoleTestingResult.jpg|thumb|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.

@@ Line 4: / Line 4: @@
 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.
 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.
@@ Line 14: / Line 13: @@
 In this area you can test the services already configured.
-The configurable tests in Testing Area are related to the following EJBs:
+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'' process is divided into three steps:

@@ Line 10: / Line 10: @@
 =={{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 simulating a client request.
-The configurable tests in Test Area are related to the following EJBs:
+In this area you can test the services already configured.
 * '''Core''' to test the direct call to the EJB of GreenVulcano’s Core.

@@ Line 3: / Line 3: @@
 [[File:GVConsoleTesting.jpg|thumb|Testing section]]
-''Testing'' is a Web application that provides a {{GVESB}} service invocation simulating a client request.
+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.
 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==

← Older revision		Revision as of 17:38, 16 February 2012
Line 12:		Line 12:

	{{L_GVCONSOLE}} offers the ''Testing'' area for testing the services already configured.		{{L_GVCONSOLE}} offers the ''Testing'' area for testing the services already configured.
		+
		+	The configurable tests in Test Area are related to the following EJBs:
		+
		+	* '''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'' process is divided into three steps:

← Older revision		Revision as of 17:27, 16 February 2012
Line 121:		Line 121:


		+
		+
		+	[[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:




−	~~[[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:~~

@@ Line 116: / Line 116: @@
 [[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.
 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:

← Older revision		Revision as of 17:26, 16 February 2012
Line 110:		Line 110:
	[[File:GVConsoleTestingDataInputFile.jpg\|thumb\|Test output: file writing]]		[[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:		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]]
		+	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.
		+
		+	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:
		+
		+
		+
		+
		+
		+	[[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:
		+
		+
		+	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.
		+
		+	===Exceptions===
		+
		+	[[File:GVConsoleTestingException.jpg\|thumb\|Wrong Paradigm Error]]
		+	Each found error will put with the input visualization the exception stack trace.
		+
		+
		+	The following picture shows a service invocation failed because of followed with the wrong paradigm:

@@ Line 11: / Line 11: @@
 =={{GVCONSOLE}} Configuration==
-{{L_GVCONSOLE}} offers the ''Testing'' area for testing the services already configured. The ''testing'' process is divided into three steps:
+{{L_GVCONSOLE}} offers the ''Testing'' area for testing the services already configured.
 * [[#Data input|Data input]]
@@ Line 89: / Line 91: @@
 * ''GVSupport.xml''
 This file will be configurable through the {{GVESB}} interface.
@@ Line 96: / Line 97: @@
-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.
+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.