Scout/Concepts/Testing Support

The Scout documentation has been moved to https://eclipsescout.github.io/.

This page describes the support included in Scout to test your Scout Application.

Type of tests

JUnit is probably one of the most well-known tools in the library community. In the context of testing scout application, it is used as base for different kind of test (not only unit tests).

Unit tests

Those tests are plain JUnit tests. They need to be executed quickly and provide immediate feeback on what a method is doing. They are useful for testing small units of code without any other dependencies.

Unit tests with Scout context

Eclipse Scout relies on OSGi for its dependency lookup mechanism. Without an OSGi context, a call to SERVICES.getService(..) in the Eclipse Scout code will return null, producing ugly null pointer exceptions. The Eclipse Scout Framework provides a small extension to JUnit: specific runners (The Scout documentation has been moved to https://eclipsescout.github.io/., The Scout documentation has been moved to https://eclipsescout.github.io/.) that ensures that the OSGi context is loaded before the tests are executed. This may slow down the test execution, but it also opens up new perspectives. For example it is possible to exchange a real service (a call to the server) with a mocked one. The test becomes decoupled from the real service implementation and it is possible to test the code against different responses of the service.

Tests with UI interaction

An important part of Eclipse Scout is that the application representation (model) is rendered at runtime with one of the renderer. From a technical point of view, the rendering occurred in the UI thread and the model lives in memory in another thread.

You might want to write test where some action are executed in the UI (mouse movement, click, keyboard action…) to see how the UI and the model react to those events. Again based on JUnit, the Scout Framework provides an abstract class for tests The Scout documentation has been moved to https://eclipsescout.github.io/.. For each tests two methods needs to be implemented: runModel() and runGui(IGuiMock). During the execution of those tests java.awt.Robot is used to take control of the keyboard and mouse.

Test with automated testing tool

These tools (have a look at Jubula if you want to use an open-source eclipse project) are working on a different layer: they consider the whole application as a black box. There is some scripting possibility to execute UI operation but this isn’t coding as a developer understand it. The target users are more Q&A members.

These tools are great for Acceptance testing and Regression testing. It is recommended to test the happy path with these tools, to ensure that the key feature of the application can be used.

Executing your tests

For the tests writen with JUnit. They can be plain JUnit tests or JUnit tests requesting an OSGi container (Plugin tests).

From the IDE

You can run the tests from your IDE.

If you are running a plain JUnit tests, select Run As > JUnit Test

If your tests require an OSGi container (this is the case for all tests requesting to run within a Scout context), select Run As > JUnit Plug-in Test. Be aware that if you run this menu without any additional precaution, all the plugins contained in your workspace will be started. This takes too long and generates unnecessary errors. Reduce the list of started plugins in the launch configuration.

With maven tycho surefire

With an application

Scout additions to support tests

TODO

• ScoutAssert, ScoutClientAssert
• Test runners
• Test executor
• @DevTestMarker

Alternative implementation for services

When your application works in the client/server mode, some services implementation requires a server. Those services are called “client proxy” (check for classes ending with *ClientProxy).

It is of course not possible to use them in a client-only test case scenario (where all the services connecting to the server are mocked). Scout provides some alternative implementation that can be used in the client tests.

TestingCodeService

The Scout documentation has been moved to https://eclipsescout.github.io/. is an implementation for The Scout documentation has been moved to https://eclipsescout.github.io/. that can override the default The Scout documentation has been moved to https://eclipsescout.github.io/. provided by scout.

The constructor expects a list of code types that will be served by this code service.

Usage example:

ICodeService codeService = new TestingCodeService(Arrays.asList(
    new CompanyCodeType(),
    new CountryCodeType()
    ));
m_registeredServices = TestingUtility.registerServices(Activator.getDefault().getBundle(), 500, codeService);

In this case the service is registered with a priority of 500. This is superior than the priority of The Scout documentation has been moved to https://eclipsescout.github.io/. registered with a default priority of -3.

TestingBatchLookupService

bug 447592

See also

• All Eclipse Scout Concepts