DICOM Application Hosting Testing - Revision history

Wolf: Distinguish SOAP API testing from integration testing

2013-11-08T12:02:57Z

Distinguish SOAP API testing from integration testing

@@ Line 1: / Line 1: @@
 === High - level test suites ===
@@ Line 33: / Line 36: @@
 * I have changed the enpoint that we use normally in the examples. (This is under the tab Service Enpoints when you double click on your project). I have tried for example to send a cancel request to the HostedApp plugin by simulating some requests from the hosting system. I received a notification that a message was received on the HostedApp but i didn't get the answer of my request: I am probably missing something in the way I set the endpoints...
 * I recommend to use the trial version of SoapUI if you are willing to do some tests. The editing of your soap message  is much simpler in the pro version.

Sascha at 14:35, 28 November 2011

2011-11-28T14:35:14Z

← Older revision		Revision as of 14:35, 28 November 2011
Line 25:		Line 25:
	* No C++ involved, create test cases in the GUI		* No C++ involved, create test cases in the GUI
	* No programming knowledge required to add or modify tests		* No programming knowledge required to add or modify tests

			==== SoapUI Experiences ====

			Just some pieces of information we (Michael C.) gathered during the Sophia-Antipolis Hackfest

			* The soapUI project files are located under the dah-testing-soapui branch. I have put two xml files there: HostService-SoapUI.xml and Application-SoapUI.xml under Plugins\org.commontk.dah.core\Resources that correspond to the SoapUI projects and that needs to be imported in SoapUI.
			* I have changed the enpoint that we use normally in the examples. (This is under the tab Service Enpoints when you double click on your project). I have tried for example to send a cancel request to the HostedApp plugin by simulating some requests from the hosting system. I received a notification that a message was received on the HostedApp but i didn't get the answer of my request: I am probably missing something in the way I set the endpoints...
			* I recommend to use the trial version of SoapUI if you are willing to do some tests. The editing of your soap message is much simpler in the pro version.

Sascha at 11:22, 14 November 2011

2011-11-14T11:22:56Z

← Older revision		Revision as of 11:22, 14 November 2011
Line 1:		Line 1:
	==== High - level test suites ====		=== High - level test suites ===

	That's what I can see so far:		That's what I can see so far:
Line 6:		Line 6:
	* Functional testing: Test the "logic" of the host and app (proper state transitions, correct notification messages, etc.)		* Functional testing: Test the "logic" of the host and app (proper state transitions, correct notification messages, etc.)

	==== Possible solutions ====		=== Possible solutions ===

	Use [http://www.soapui.org/ SoapUI] and its command line support to integrate it with ctest. Automatically generate tests for WSDL compliance using the official WSDL file		* Use [http://www.soapui.org/ SoapUI] and its command line support to integrate it with ctest.
	* Create manual functional tests within the SoapUI GUI and put the project file in the CTK git repository		** Automatically generate tests for WSDL compliance using the official WSDL file
			** Create manual functional tests within the SoapUI GUI and put the project file in the CTK git repository

	==== ~~Requires~~ ====		==== SoapUI ====

			'''Requires'''

	* Either host the SoapUI executable somewhere or look for it if testing is enabled		* Either host the SoapUI executable somewhere or look for it if testing is enabled
Line 17:		Line 20:
	* Some CMake magic		* Some CMake magic

	~~====~~ Pros ~~====~~		'''Pros'''

	* Rely on proven Java libraries to generate the RPC stuff and mock classes for server and client code from the WSDL file.		* Rely on proven Java libraries to generate the RPC stuff and mock classes for server and client code from the WSDL file.
	* No C++ involved, create test cases in the GUI		* No C++ involved, create test cases in the GUI
	* No programming knowledge required to add or modify tests		* No programming knowledge required to add or modify tests

Sascha: /* Possible solutions */

2011-11-14T11:19:10Z

Possible solutions

← Older revision		Revision as of 11:19, 14 November 2011
Line 8:		Line 8:
	==== Possible solutions ====		==== Possible solutions ====

	Use SoapUI and its command line support to integrate it with ctest. Automatically generate tests for WSDL compliance using the official WSDL file		Use [http://www.soapui.org/ SoapUI] and its command line support to integrate it with ctest. Automatically generate tests for WSDL compliance using the official WSDL file
	* Create manual functional tests within the SoapUI GUI and put the project file in the CTK git repository		* Create manual functional tests within the SoapUI GUI and put the project file in the CTK git repository

Sascha: Created page with "==== High - level test suites ==== That's what I can see so far: * WSDL compliance: Test if the host and app accept the official method signatures * Functional testing: Test th..."

2011-11-14T11:18:01Z

Created page with "==== High - level test suites ==== That's what I can see so far: * WSDL compliance: Test if the host and app accept the official method signatures * Functional testing: Test th..."

New page

==== High - level test suites ====

That's what I can see so far:

* WSDL compliance: Test if the host and app accept the official method signatures
* Functional testing: Test the "logic" of the host and app (proper state transitions, correct notification messages, etc.)

==== Possible solutions ====

Use SoapUI and its command line support to integrate it with ctest. Automatically generate tests for WSDL compliance using the official WSDL file
* Create manual functional tests within the SoapUI GUI and put the project file in the CTK git repository

==== Requires ====

* Either host the SoapUI executable somewhere or look for it if testing is enabled
* Java Runtime on the test system
* Some CMake magic

==== Pros ====

* Rely on proven Java libraries to generate the RPC stuff and mock classes for server and client code from the WSDL file.
* No C++ involved, create test cases in the GUI
* No programming knowledge required to add or modify tests