|
|
| (One intermediate revision by one other user not shown) |
| Line 1: |
Line 1: |
| − | {{ScoutPage|cat=Concepts}}
| + | The Scout documentation has been moved to https://eclipsescout.github.io/. |
| − | | + | |
| − | This Page describes the architecture we want to obtain for the Scout Test Infrastructure (Testing support: how to test a scout application, but also unit test for Scout RT and SDK). See [http://www.bsiag.com/scout/?p=635 Scout Roadmap] for more information.
| + | |
| − | | + | |
| − | ''Please do not change the title of the sections''
| + | |
| − | | + | |
| − | {{Warning|Work in progress|This page is for now more a road-map and a TODO list. Goal is to have an overview from the different component instead}}
| + | |
| − | | + | |
| − | | + | |
| − | == RT ==
| + | |
| − | The RT Code contains some classes used before JUnit (ITest, AbstractClientTest, AbstractServerTest, ...). This approach should no longer be used.
| + | |
| − | | + | |
| − | === TODO ===
| + | |
| − | * {{FixedBug|397085}}: <s>Mark legacy testing support as deprecated</s>
| + | |
| − | | + | |
| − | | + | |
| − | == RT.Testing ==
| + | |
| − | Theses plugins contains classes for testing support: this is a collection of classes (JUnit test runner, Utility, Abstract Test classes…) that can be used to write JUnit tests for Scout Applications.
| + | |
| − | | + | |
| − | '''Naming convention''': please do not name the classes with a <code>Test</code> suffix. Prefer <code>TestingSupport</code> or something like that.
| + | |
| − | | + | |
| − | List of plugins:
| + | |
| − | * org.eclipse.scout.rt.testing.client
| + | |
| − | * org.eclipse.scout.rt.testing.shared
| + | |
| − | * org.eclipse.scout.rt.testing.server
| + | |
| − | * org.eclipse.scout.rt.testing.ui.rap
| + | |
| − | * org.eclipse.scout.rt.testing.swing
| + | |
| − | * org.eclipse.scout.rt.testing.swt
| + | |
| − | | + | |
| − | This plugins are exposed in a testing feature.
| + | |
| − | | + | |
| − | This plugins are also used in the [[#RT.Test|RT.Test]] fragments (Theses tests are also using JUnit to write tests).
| + | |
| − | | + | |
| − | == RT.Test ==
| + | |
| − | All modifications are tracked here in {{Bug|402298}} (and sub bugs).
| + | |
| − | {{Note|Work in progress|The sanbox Branch for these modifications is hosted on GitHub [http://github.com/BSI-Business-Systems-Integration-AG/scout.rt/tree/master_testing master_testing]. The change are progressively merged into the master }}
| + | |
| − | | + | |
| − | === Type of tests ===
| + | |
| − | Eclipse Scout Test suite is composed of different test type:
| + | |
| − | | + | |
| − | ==== JUnit Tests ====
| + | |
| − | This set of fragments contains the tests to test the runtime classes:
| + | |
| − | | + | |
| − | Naming convention:
| + | |
| − | * org.eclipse.scout.rt.client
| + | |
| − | ** => org.eclipse.scout.rt.client.test
| + | |
| − | * org.eclipse.scout.rt.shared
| + | |
| − | ** => org.eclipse.scout.rt.shared.test
| + | |
| − | * org.eclipse.scout.rt.server
| + | |
| − | ** => org.eclipse.scout.rt.server.test
| + | |
| − | *...
| + | |
| − | | + | |
| − | The test classes should be in the same package than the class under test:
| + | |
| − | * tests for org.eclipse.scout.commons.CompareUtility
| + | |
| − | ** => are located in org.eclipse.scout.commons.CompareUtilityTest (located in the org.eclipse.scout.commons.test fragment).
| + | |
| − | The Abstract prefix can be removed:
| + | |
| − | * tests for org.eclipse.scout.rt.client.ui.basic.table.AbstractTable
| + | |
| − | ** => are located in org.eclipse.scout.rt.client.ui.basic.table.TableTest (located in the org.eclipse.scout.rt.client.test fragment).
| + | |
| − | | + | |
| − | These tests use the JUnit testing framework and are executed by maven-tycho during the build.
| + | |
| − | * Plain JUnit: These are the classical JUnit tests for methods which do not have to be run within the Scout / Equinox context and therefore do not require any Scout services.
| + | |
| − | * JUnit with Equinox Context: These JUnit tests are responsible for checking the functions and operations of the Scout client model and of the Scout server. These tests need to be run within a Scout / Equinox context. They use the JUnit annotation @RunWith combined with the Scout TestRunner.
| + | |
| − | | + | |
| − | To install the Scout context, the CustomClientTestEnvironment and CustomServerTestEnvironment are used used. These classes are in the plugins:
| + | |
| − | * org.eclipse.scout.rt.client.testenvironment
| + | |
| − | * org.eclipse.scout.rt.server.testenvironment
| + | |
| − | | + | |
| − | This means that
| + | |
| − | * Each test fragment using ScoutClientTestRunner need to add a dependency on org.eclipse.scout.rt.client.testenvironment.
| + | |
| − | * Each test fragment unsing ScoutServerTestRunner need to add a dependency on org.eclipse.scout.rt.server.testenvironment
| + | |
| − | | + | |
| − | ==== Test requiring an OS with graphical layer ====
| + | |
| − | Those tests are exactly the same as the one of the first type, but they use libraries (Swing, AWT, SWT…) requiring a graphical layer in the operating system.
| + | |
| − | | + | |
| − | All the same rules apply to these tests, but we use a other suffix. Instead of using just <code>Test</code> we use <code>UiTest</code>.
| + | |
| − | | + | |
| − | We do not mix the test of the first category with this one, because we want to be able to skip these tests if the maven build is triggered on a computer without a graphical layer. If maven is executed on a command-line terminal, the JUnit tests that require an Operating System with a graphical layer need to be ignored.
| + | |
| − | | + | |
| − | {{Note|TODO|specify the Maven profiles|}}.
| + | |
| − | | + | |
| − | Another alternative on computers without a graphical layer is to use a virtual graphical layer like [http://en.wikipedia.org/wiki/Xvfb xvfb] or xVNC.
| + | |
| − | See pointer by cloudbees: [http://wiki.cloudbees.com/bin/view/DEV/Testing+GUI+applications Testing GUI applications]
| + | |
| − | | + | |
| − | ==== Integration tests ====
| + | |
| − | These tests operate on another level. They are also executed as JUnit test, but they operate on the forms and widgets directly. They need a complete application; often a server and they use the computer controls (they move the mouse, they emulate a key,…).
| + | |
| − | | + | |
| − | It should be a possibility to trigger this test with different UIs (SWT, Swing with different Look and Feel, RAP…) different Java Version and in the best case with different operating system.
| + | |
| − | | + | |
| − | It is not so clear, if this integration tests needs to be built on each platform or if they can share some bin files.
| + | |
| − | | + | |
| − | | + | |
| − | === Long term vision ===
| + | |
| − | Plain JUnit is the preferred way (state of the art, faster during execution, easier to set up…). This is something we need to consider.
| + | |
| − | | + | |
| − | The long term vision for Eclipse Scout Code should be to have code that can be tested with plain JUnit. To achieve the goal, the static Utility classes (SERVICES, TEXTS, ...) should not be used. Instead of getting the instance (dependency Lookup), the code should use the correct interface directly and let someone else provide it (could also be with dependency injection).
| + | |
| − | | + | |
| − | | + | |
| − | Here a small example:
| + | |
| − | | + | |
| − | | + | |
| − | This code requires a an Eclipse Equinox Context:
| + | |
| − | <source lang="java">
| + | |
| − | class Foo {
| + | |
| − | | + | |
| − | public void doBar() throws ProcessingException {
| + | |
| − | SERVICES.getService(IFooService).doBar();
| + | |
| − | }
| + | |
| − | }
| + | |
| − | </source>
| + | |
| − | | + | |
| − | This code can be tested with plain JUnit:
| + | |
| − | <source lang="java">
| + | |
| − | class Foo {
| + | |
| − |
| + | |
| − | private IFooService service;
| + | |
| − | | + | |
| − | Foo(IFooService service) {
| + | |
| − | this.service = service;
| + | |
| − | }
| + | |
| − | | + | |
| − | public void doBar() throws ProcessingException {
| + | |
| − | service.doBar();
| + | |
| − | }
| + | |
| − | }
| + | |
| − | </source>
| + | |
| − | | + | |
| − | === Coding/Naming convention ===
| + | |
| − | * Fragment name should be: <plugin name>+".test" without ".fragment". (example org.eclipse.scout.rt.client.test for org.eclipse.scout.rt.client)
| + | |
| − | | + | |
| − | * JavaDoc:
| + | |
| − | On top of each class, at least:
| + | |
| − | <source lang="java">
| + | |
| − | /**
| + | |
| − | * JUnit tests for {@link <class name>}
| + | |
| − | *
| + | |
| − | * @since 3.9.0
| + | |
| − | */
| + | |
| − | </source>
| + | |
| − | | + | |
| − | | + | |
| − | * Fixture:
| + | |
| − | [[Image:Scout Test Fixture.png|rigth|thumb|300px|ConfigurationUtilityTest]]
| + | |
| − | | + | |
| − | When tests need additional java Object, they are added in a <code>fixture</code> sub-package.
| + | |
| − | | + | |
| − | See example:
| + | |
| − | <code>org.eclipse.scout.commons.ConfigurationUtilityTest</code> uses:
| + | |
| − | * <code>org.eclipse.scout.commons.fixture.A</code>
| + | |
| − | * <code>org.eclipse.scout.commons.fixture.AbstractC</code>
| + | |
| − | | + | |
| − | See also [http://sqa.fyicenter.com/FAQ/JUnit/What_Is_a_JUnit_Test_Fixture_.html What Is a JUnit Test Fixture?]
| + | |
| − | | + | |
| − | == SDK.Test ==
| + | |
| − | | + | |
| − | Same approach as the [[#RT.Test|RT.Test]] but for the SDK.
| + | |
| − | | + | |
| − | === TODO ===
| + | |
| − | * Create the necessary plugins/fragments
| + | |
| − | * Create a POC: some tests + maven/tycho build that execute the tests (depending on the hardware).
| + | |
| − | | + | |
| − | | + | |
| − | == SDK Test support ==
| + | |
| − | Setting-up all the plugins to test a scout application is not easy. For the moment this operation is achieve by hand. This know-how should be integrated in the Scout SDK, so that it becomes simple to start writing tests for a scout application.
| + | |
| − | | + | |
| − | === TODO ===
| + | |
| − | * {{Bug|394136}}: Create test infrastructure when creating a Scout project
| + | |
