Jump to: navigation, search

Difference between revisions of "SCA/Components/SCA Testing SCA Applications"

< SCA
 
(16 intermediate revisions by 2 users not shown)
Line 2: Line 2:
  
 
One important aspect that can influence a team or a company to choose SCA for its development is the efficiency and the cost of developments with this technology. Clearly, SCA provides a powerful and very easy way to write distributed applications. But if these applications are difficult to test, there are few chances for SCA to be adopted.  
 
One important aspect that can influence a team or a company to choose SCA for its development is the efficiency and the cost of developments with this technology. Clearly, SCA provides a powerful and very easy way to write distributed applications. But if these applications are difficult to test, there are few chances for SCA to be adopted.  
 +
  
 
Obviously, who has already written an SCA application does already know that conventional testing tools can be used to test component implementations, and that with an adapted project management, a progressive and planned development can permit to correctly test an SCA application.  
 
Obviously, who has already written an SCA application does already know that conventional testing tools can be used to test component implementations, and that with an adapted project management, a progressive and planned development can permit to correctly test an SCA application.  
  
 
However, such an organization sets several constraints on the management. As an example, it requires you to make your composite assembly evolve continually so that you can progressively test the components and their integration. And in this case, perform non-regression tests is very difficult.
 
However, such an organization sets several constraints on the management. As an example, it requires you to make your composite assembly evolve continually so that you can progressively test the components and their integration. And in this case, perform non-regression tests is very difficult.
 +
  
 
This is why tools should be proposed to simplify and improve the tests of SCA applications.  
 
This is why tools should be proposed to simplify and improve the tests of SCA applications.  
Line 17: Line 19:
 
== Unit Test ==
 
== Unit Test ==
  
Unit test for SCA is about testing services of a component or a composite and ensure their contract is fully respected. These tests must be performed on isolated elements, that is to say dependencies (i.e. references) must be mocked up.
+
Unit test for SCA is about testing services of a component or a composite and ensure their contract was correctly implemented. These tests must be performed on isolated elements, that is to say dependencies (i.e. references) must be mocked up. If you do not isolate them, then errors might come from this component or from its dependencies.
  
 
To achieve that, we can use JUnit and EasyMock. This what the SCA platform [http://fabric3.codehaus.org/ Fabric3] has done.
 
To achieve that, we can use JUnit and EasyMock. This what the SCA platform [http://fabric3.codehaus.org/ Fabric3] has done.
Line 23: Line 25:
 
For any element to test, the user has to write TestCases (as he would do for any JUnit test) where he mocks the references, calls service operations and checks assertions on the results.
 
For any element to test, the user has to write TestCases (as he would do for any JUnit test) where he mocks the references, calls service operations and checks assertions on the results.
  
No tool can be easily provided to say whether the user wrote a good test or not. However, we can:
+
 
 +
No tool can be provided to say whether the user wrote a good test or not. However, we can:
 
* Bring support and useability when defining a test and managing testing code (e.g. which component / composite is this test for ?).
 
* Bring support and useability when defining a test and managing testing code (e.g. which component / composite is this test for ?).
* Improve the speed of development, e.g. by setting JUnit and Easymock directly in the class path and generate TestCase skeletons.
+
* Improve the speed of development with code generation.
 
* Allow users to run SCA JUnit tests from Eclipse on a user-selected platform, and display the results in the usual Eclipse JUnit view.
 
* Allow users to run SCA JUnit tests from Eclipse on a user-selected platform, and display the results in the usual Eclipse JUnit view.
  
Basically, the idea is to allow what [http://fabric3.codehaus.org/ Fabric3] allows for unit and integration tests, but in a way that permits to run these tests on any SCA platform. (Currently, [[http://fabric3.codehaus.org/ Fabric3]] has defined specific modules to run this kind of tests). What we would like to do is embed testing code in a ''simple'' Java implementation.
 
  
Since this not easy to explain, this kind of test is better explained in the following pages:
+
Basically, the idea is to allow what [http://fabric3.codehaus.org/ Fabric3] allows for unit and integration tests, but in a way that permits to run these tests on any SCA platform. (Currently, [http://fabric3.codehaus.org/ Fabric3] has defined specific modules to run this kind of tests). What we would like to do is to embed test code in a ''simple'' Java implementation.
* [[STP/SCA_Component/SCA_Testing_SCA_Applications_Unit_Example|A Detailed Example of an SCA Application of Unit Test]]
+
* [[STP/SCA_Component/SCA_Testing_SCA_Applications_Principles|The Principles of Testing Tool for SCA]]
+
  
 +
Unit tests for SCA are better discussed in the following pages:
 +
* [[STP/SCA_Component/SCA_Testing_SCA_Applications_Unit_Example|A Detailed Example of an SCA Application with Unit Testing]]
 +
* [[STP/SCA_Component/SCA_Testing_SCA_Applications_Principles|The Principles of Unit and Integration Testing Tools for SCA]]
 +
 +
<br />
  
 
== Integration Test ==
 
== Integration Test ==
  
 
Integration tests for SCA are very similar to unit tests in the way we define and run them.
 
Integration tests for SCA are very similar to unit tests in the way we define and run them.
It still consists in writing TestCases, but this time, we progressively replace mocked up references by effective references.
+
It still consists in writing TestCases, but this time, we progressively replace mocked up references by effective references (at least, this is a way to perform integration test). So, the main difference between unit and integration test is the number of mocked up references.
  
As the continuation of the previous example, integration tests are discussed here:
 
* [[STP/SCA_Component/SCA_Testing_SCA_Applications_Integration_Example|A Detailed Example of an SCA Application of Integration Test]]
 
* [[STP/SCA_Component/SCA_Testing_SCA_Applications_Principles|The Principles of Testing Tool for SCA]]
 
  
 +
You can see the previous section about unit test or take a look at [[STP/SCA_Component/SCA_Testing_SCA_Applications_Principles|the Principles of Unit and Integration Testing Tools for SCA]].
  
 +
<br />
 
== Manual Test / Debugging ==
 
== Manual Test / Debugging ==
  
The two previous testing tools may be done in fall 2008.
+
The two previous testing tools have been experimented whereas the following tools would need additional thinking.
The following tools would need additional thinking. They are really just ideas.
+
 
 +
Other ideas were proposed on the [http://www.mail-archive.com/tuscany-user@ws.apache.org/msg03253.html Tuscany mailing-list] and might be a further inspiration source.
  
  
 
=== Debugging support ===
 
=== Debugging support ===
  
Unit and integration tests can be run on platform by right-clicking on the TestCase to run and then by selecting the runtime platform. We could also imagine to run these tests in debug mode. Playing with Java options might be enough to do that.
+
Unit and integration tests can be run on platform by right-clicking on the required TestCase and then by selecting the runtime platform. We could also imagine to run these tests in debug mode. Playing with Java options might be a solution to do that.
  
 
Users could then add breakpoints in their implementation code. Reaching such a breakpoint would then propose the user to run the debug perspective in Eclipse. Obviously, this would be possible only for languages that support breakpoints (e.g. Java).
 
Users could then add breakpoints in their implementation code. Reaching such a breakpoint would then propose the user to run the debug perspective in Eclipse. Obviously, this would be possible only for languages that support breakpoints (e.g. Java).
Line 62: Line 67:
 
We may imagine users that would like to test which messages go through service and reference bindings at runtime. This is a feature we could provide in the SCA tooling.
 
We may imagine users that would like to test which messages go through service and reference bindings at runtime. This is a feature we could provide in the SCA tooling.
  
By adding breakpoints on the SCA Composite Designer or in the XML editor for *.composite files, the debug perspective could be proposed to be launched when such a breakpoint is reached.  
+
By adding breakpoints on the SCA Composite Designer or in the XML editor, the debug perspective could be launched when such a breakpoint is reached.  
  
In terms of development, this might be achieved by identifying which class and in which platform is in charge of handling messages for the annotated binding.
+
In terms of development, this might be achieved by identifying which class (and in which platform) is in charge of handling messages for the annotated binding.
  
  
Line 70: Line 75:
  
 
Eventually, users would also need an invocation form to call and test services “by hand”.
 
Eventually, users would also need an invocation form to call and test services “by hand”.
Typically, it would look like the Web Service Explorer of Eclipse. We would select a service in a composite and ask to call it using the invocation form. Using the interface of this service, Eclipse would generate a Web form to call this service.  
+
Typically, it would look like the Web Service Explorer of Eclipse. We would select a service in a composite and ask to call it using the invocation form. Using the interface of this service (parameters description), Eclipse would generate a Web form to call this service and call this service with user-defined parameters.
 +
 
 +
The result would then be displayed on screen.
 +
This invocation form could also be used as a general service tester, since SCA bindings can be used to access any service type, even from non-SCA applications (once again by dynamically generating an SCA application to call the service to test).
 +
 
  
The result would then be retrieved and displayed on screen.
+
[[Category:SOA_Tools]]
This invocation form could also be used as a general service tester, since SCA bindings can be used to access any service type (once again by generating dynamically a SCA application to call the service to test).
+
[[Category:SOA]]
 +
[[Category:STP]]
 +
[[Category:SCA]]

Latest revision as of 11:00, 8 July 2010

Testing SCA Applications

One important aspect that can influence a team or a company to choose SCA for its development is the efficiency and the cost of developments with this technology. Clearly, SCA provides a powerful and very easy way to write distributed applications. But if these applications are difficult to test, there are few chances for SCA to be adopted.


Obviously, who has already written an SCA application does already know that conventional testing tools can be used to test component implementations, and that with an adapted project management, a progressive and planned development can permit to correctly test an SCA application.

However, such an organization sets several constraints on the management. As an example, it requires you to make your composite assembly evolve continually so that you can progressively test the components and their integration. And in this case, perform non-regression tests is very difficult.


This is why tools should be proposed to simplify and improve the tests of SCA applications.

Here are some ideas of tools to test SCA applications, picked up from Fabric3, Tuscany and SCOrWare mailing-lists:

  • Unit test
  • Integration test
  • Manual test / Debugging


Unit Test

Unit test for SCA is about testing services of a component or a composite and ensure their contract was correctly implemented. These tests must be performed on isolated elements, that is to say dependencies (i.e. references) must be mocked up. If you do not isolate them, then errors might come from this component or from its dependencies.

To achieve that, we can use JUnit and EasyMock. This what the SCA platform Fabric3 has done.

For any element to test, the user has to write TestCases (as he would do for any JUnit test) where he mocks the references, calls service operations and checks assertions on the results.


No tool can be provided to say whether the user wrote a good test or not. However, we can:

  • Bring support and useability when defining a test and managing testing code (e.g. which component / composite is this test for ?).
  • Improve the speed of development with code generation.
  • Allow users to run SCA JUnit tests from Eclipse on a user-selected platform, and display the results in the usual Eclipse JUnit view.


Basically, the idea is to allow what Fabric3 allows for unit and integration tests, but in a way that permits to run these tests on any SCA platform. (Currently, Fabric3 has defined specific modules to run this kind of tests). What we would like to do is to embed test code in a simple Java implementation.

Unit tests for SCA are better discussed in the following pages:


Integration Test

Integration tests for SCA are very similar to unit tests in the way we define and run them. It still consists in writing TestCases, but this time, we progressively replace mocked up references by effective references (at least, this is a way to perform integration test). So, the main difference between unit and integration test is the number of mocked up references.


You can see the previous section about unit test or take a look at the Principles of Unit and Integration Testing Tools for SCA.


Manual Test / Debugging

The two previous testing tools have been experimented whereas the following tools would need additional thinking.

Other ideas were proposed on the Tuscany mailing-list and might be a further inspiration source.


Debugging support

Unit and integration tests can be run on platform by right-clicking on the required TestCase and then by selecting the runtime platform. We could also imagine to run these tests in debug mode. Playing with Java options might be a solution to do that.

Users could then add breakpoints in their implementation code. Reaching such a breakpoint would then propose the user to run the debug perspective in Eclipse. Obviously, this would be possible only for languages that support breakpoints (e.g. Java).


Monitoring Service and Reference Messages

We may imagine users that would like to test which messages go through service and reference bindings at runtime. This is a feature we could provide in the SCA tooling.

By adding breakpoints on the SCA Composite Designer or in the XML editor, the debug perspective could be launched when such a breakpoint is reached.

In terms of development, this might be achieved by identifying which class (and in which platform) is in charge of handling messages for the annotated binding.


Invocation Form

Eventually, users would also need an invocation form to call and test services “by hand”. Typically, it would look like the Web Service Explorer of Eclipse. We would select a service in a composite and ask to call it using the invocation form. Using the interface of this service (parameters description), Eclipse would generate a Web form to call this service and call this service with user-defined parameters.

The result would then be displayed on screen. This invocation form could also be used as a general service tester, since SCA bindings can be used to access any service type, even from non-SCA applications (once again by dynamically generating an SCA application to call the service to test).