Community
Participate
Working Groups
Testing Scout applications is typically driven by Scout's testing support (i.e. org.eclipse.scout.rt.testing.* bundles). It is a thin layer based on JUnit. The JUnitTestClassBrowser is looking for JUnit classes in the currently running OSGi environment and the ScoutJUnitPluginTestExecutor that is actually executing the tests. It is currently not possible to configure the JUnitTestClassBrowser. The set of bundles tests are searched in and the set of tests should be configurable. The ScoutJUnitPluginTestExecutor exits with a non-zero return value if some tests fail. It should be possible to specify this behavior from outside (like it is possible for Ant's JUnit task).
Some more improvements: 1. Apparently it is now possible to define the set of bundles with the command line argument bundleNameIncludeFilter which is fine. If the tests lie in a fragment it would be natural to specify these fragments. Unfortunately this is not possible. Allowing to specify the fragments and not only the host bundle would massively improve the performance since the host bundle typically contains a lot more classes than the test-fragment. 2. When running a test which opens a messagebox the class DefaultTestClientSessionProvider makes sure that a messagebox will automatically be closed by clicking the cancel button. In my case I need to close the messagebox with the ok button. It is already possible to achieve that by overriding DefaultTestClientSessionProvider, but it is a little too complicated since I need to copy some stuff. Overriding DefaultTestClientSessionProvider is fine but setting the messagebox closing type should be easier. 3. After opening a form the caller often waits for its closing with the use of IForm.waitFor();. If a test leads to a button click which contains such logic the test freezes. The scout testing support should contain a solution for this problem. One could be to register a listener on the ClientJob which allows execution of code before it eventually locks the object.
This bug must be reviewed and evaluated. Is it still relevant to the current implementation ?
obsolete
