Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Scout/Concepts/Testing Support"

(Scout additions to support tests)
(Replaced content with "The Scout documentation has been moved to https://eclipsescout.github.io/.")
 
Line 1: Line 1:
{{ScoutPage|cat=Concepts}}
+
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 <tt>SERVICES.getService(..)</tt> 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 ({{ScoutJavadoc|ScoutClientTestRunner|C}}, {{ScoutJavadoc|ScoutServerTestRunner|C}}) 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 {{ScoutJavadoc|AbstractTestWithGuiScript|C}}. For each tests two methods needs to be implemented: <tt>runModel()</tt> and <tt>runGui(IGuiMock)</tt>. During the execution of those tests <tt>java.awt.Robot</tt> is used to take control of the keyboard and mouse.
+
 
+
=== Test with automated testing tool ===
+
These tools (have a look at [http://eclipse.org/jubula/ 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.
+
 
+
[[File:Executing_scout_tests_from_the_IDE.png]]
+
 
+
If you are running a plain JUnit tests, select <code>Run As > JUnit Test</code>
+
 
+
If your tests require an OSGi container (this is the case for all tests requesting to run within a Scout context), select <code>Run As > JUnit Plug-in Test</code>. 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 ===
+
[[File:Executing_scout_tests_with_maven_tycho_surefire.png]]
+
 
+
=== With an application ===
+
[[File:Executing_scout_tests_with_an_application.png]]
+
 
+
== Scout additions to support tests ==
+
{{Note|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 <code>*ClientProxy</code>).
+
 
+
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 ===
+
{{ScoutJavadoc|TestingCodeService|c}} is an implementation for {{ScoutJavadoc|ICodeService|i}} that can override the default {{ScoutJavadoc|CodeServiceClientProxy|c}} provided by scout.
+
 
+
The constructor expects a list of code types that will be served by this code service.
+
 
+
Usage example:
+
<source lang="java">
+
ICodeService codeService = new TestingCodeService(Arrays.asList(
+
    new CompanyCodeType(),
+
    new CountryCodeType()
+
    ));
+
m_registeredServices = TestingUtility.registerServices(Activator.getDefault().getBundle(), 500, codeService);
+
</source>
+
 
+
 
+
In this case the service is registered with a priority of <code>500</code>. This is superior than the priority of {{ScoutJavadoc|CodeServiceClientProxy|c}} registered with a default priority of <code>-3</code>.
+
 
+
=== TestingBatchLookupService ===
+
{{Bug|447592}}
+
 
+
== See also ==
+
* [[:Category:Scout_Concepts|All Eclipse Scout Concepts]]
+

Latest revision as of 05:45, 14 March 2024

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

Back to the top