Jump to: navigation, search

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

< SCA
(Integration Test)
(Unit Test)
Line 32: Line 32:
 
Since this not easy to explain, this kind of test is better explained in the following pages:
 
Since this not easy to explain, this kind of test is better explained in the following pages:
 
* [[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_Unit_Example|A Detailed Example of an SCA Application of Unit Test]]
* [[STP/SCA_Component/SCA_Testing_SCA_Applications_Principles|The Principles of Unit Testing Tool for SCA]]
+
* [[STP/SCA_Component/SCA_Testing_SCA_Applications_Principles|The Principles of Testing Tool for SCA]]
 
+
  
 
== Integration Test ==
 
== Integration Test ==

Revision as of 08:01, 21 July 2008

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 is fully respected. These tests must be performed on isolated elements, that is to say dependencies (i.e. references) must be mocked up.

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 easily 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, e.g. by setting JUnit and Easymock directly in the class path and generate TestCase skeletons.
  • 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 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:

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.

As the continuation of the previous example, integration tests are discussed here:

Manual Test / Debugging

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.

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 for *.composite files, the debug perspective could be proposed to 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, Eclipse would generate a Web form to call this service.

The result would then be retrieved and 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 (once again by generating dynamically a SCA application to call the service to test).