SCA/Components/SCA Testing SCA Applications

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:

• A Detailed Example of an SCA Application with Unit Testing
• The Principles of Unit and Integration Testing Tools for SCA

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).