|
|
| (13 intermediate revisions by the same 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''
| + | |
| − | | + | |
| − | | + | |
| − | == Demo ==
| + | |
| − | BSI has a small Demo Application (Client-side only) that displays all the fields. For the moment this application is closed source.
| + | |
| − | | + | |
| − | This application is useful to display all possibilities offered by the fields (common configuration for each field). There is no need to have this in the eclipse repository (no need for IP-Clear). Therefor the idea is to refactor the application publish it on github.
| + | |
| − | | + | |
| − | Nice to have: For each demonstrated field, we want to have a link to the GitHub java source code page.
| + | |
| − | | + | |
| − | Branch organization on GitHub should be the same as in the Eclipse Repository.
| + | |
| − | | + | |
| − | === TODO ===
| + | |
| − | * Define the project name: '''org.eclipsescout.demo.widgets'''. (mzi: As we did register the domain eclipsescout.org, such a pattern allows having other demo applications than just the widgets-demo. We want to have a consistent naming scheme that relates these demo applications to Scout)
| + | |
| − | * Create the repository in GitHub
| + | |
| − | * Create a POC
| + | |
| − | ** one page for one field
| + | |
| − | ** with link to the source code at Git-Hub
| + | |
| − | ** built with Maven Tycho
| + | |
| − | * create the rest of the pages (for the other pages) == migration of the current test application to the new widgets-demo application.
| + | |
| − | * mention the project in the scout book (mzi: i would like to use the Scout widgets demo in the book as basis for describing all the widgets in chapter 'Form Fields' of part 'The Frontend')
| + | |
| − | | + | |
| − | == 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).
| + | |
| − | | + | |
| − | === TODO ===
| + | |
| − | * {{Bug|376459}}: Add a testing feature and publish it on the Scout update site
| + | |
| − | | + | |
| − | | + | |
| − | == RT.Test ==
| + | |
| − | This set of fragments / plugins 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.rt.client.ui.basic.table.AbstractTable
| + | |
| − | ** => are located in org.eclipse.scout.rt.client.ui.basic.table.AbstractTableTest (located in the org.eclipse.scout.rt.client.test fragment).
| + | |
| − | | + | |
| − | | + | |
| − | There should be a mechanism (Annotation, special runner, test suite...) to exprim the requirements to run the test:
| + | |
| − | * Plain JUnit (Test for functions that do not require any Scout Service).
| + | |
| − | * JUnit with Equinox Context (Mocked UI Renderer plugin: test functions/operations of the client core)
| + | |
| − | * JUnit with Equinox Context and an operating system providing a graphical layer (With a UI Renderer plugin: test requiring UI Interaction).
| + | |
| − | | + | |
| − | {{Note|TODO|Input KLE: Add a description of the different type of test. eg: Automated GUI Tests for Scout Forms / Widgets, etc}}
| + | |
| − | | + | |
| − | The tests need to be executed from Maven (e.g. Surefire) to be integrated in the CBI. There is probably a way to tell maven which tests can be executed and which tests cannot. For example: 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.
| + | |
| − | | + | |
| − | | + | |
| − | For the moment, it is not sure whereas the foundation provides computers with graphical layer. The best solution is to have such computers in the eclipse foundation infrastructure. If there is no possibility to have a such computer, there is a need to evaluate the other possibilities (Cloud platform for developers, computer at BSI, ...).
| + | |
| − | | + | |
| − | === TODO ===
| + | |
| − | * Create the necessary plugins/fragments
| + | |
| − | * Create a POC: some tests + maven/tycho build that execute the tests (depending on the hardware).
| + | |
| − | * Migrate the closed-source tests to this new platform.
| + | |
| − | | + | |
| − | == 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
| + | |
