|Download • Git|
|Forums • Blog • Twitter • G+|
This page describes the support included in Scout to test your Scout Application.
- 1 Type of tests
- 2 Executing your tests
- 3 From the IDE
- 4 Scout additions to support tests
- 5 Alternative implementation for services
- 6 See also
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).
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 (
ScoutServerTestRunner ) 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
AbstractTestWithGuiScript . 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
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
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.
The constructor expects a list of code types that will be served by this code service.
ICodeService codeService = new TestingCodeService(Arrays.asList( new CompanyCodeType(), new CountryCodeType() )); m_registeredServices = TestingUtility.registerServices(Activator.getDefault().getBundle(), 500, codeService);