Bugzilla – Full Text Bug Listing
| Summary: | Provide a clean and simple structure to test Sirius | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] Sirius | Reporter: | Hugo Marchadour <hugo.marchadour> | ||||||||
| Component: | Releng | Assignee: | Project Inbox <sirius.releng-inbox> | ||||||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P3 | CC: | alex.lagarde, laurent.redor, pierre-charles.david | ||||||||
| Version: | 0.9 | Keywords: | triaged | ||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Hugo Marchadour
A little clarification, we start with a set of legacy Junit and SWTBot tests that we need to import in Sirius with the API clean process. The purpose of this task is to target a new test system. Created attachment 238192 [details]
Light sample of plugin dependencies in Sirius
I've in mind an organization like this : For each plugins, we can have its associated "*.tests" plugin in a dedicated folder called "tests" or "test-plugins" [1]. If the plugin under test is an headless plugin, it could contain unit and integration tests. If the plugin under test is an UI plugin, it could contain unit, integration and UI tests. In both cases, we have the minimal plugin dependency context during the test execution. Another test plugin called "org.eclipse.sirius.runtime.tests" could contain integration tests that have all sirius plugins in dependencies. It could also replay all integration tests. Another test plugin called "org.eclipse.sirius.runtime.ui.tests" could contain ui tests that have all sirius plugins in dependencies. It could also replay all ui tests. [1] * plugins/org.eclipse.sirius -> tests/org.eclipse.sirius.tests * plugins/org.eclipse.sirius.common -> tests/org.eclipse.sirius.common.tests * plugins/org.eclipse.sirius.ecore.extender -> tests/org.eclipse.sirius.ecore.extender.tests * plugins/org.eclipse.sirius.common.ui -> tests/org.eclipse.sirius.common.ui.tests * plugins/org.eclipse.sirius.ui -> tests/org.eclipse.sirius.ui.tests For a UI plugin, we will separate JUnit tests (Unit and integration tests) to Swtbot tests. These both cases haven't the same way to be launch in Tycho. (Expecially for useUIHarness and useUIThread tycho-surefire-plugin configurations) Basically, for org.eclipse.sirius.common.ui, we will create org.eclipse.sirius.common.ui.tests and org.eclipse.sirius.common.ui.tests.swtbot. To separate Unit and Integration tests, we may have a dedicated source folder /unit /integ. For package names, we will follow the package of the Class under test. For the integration test, it's still to define. About a common SDK for testing, we have several things in mind. Firstly, all generic test helpers that could be proposed as Eclipse submission (like a generic wait condition) will be added in the library extensions. For example: * org.eclipse.sirius.ext.junit * org.eclipse.sirius.ext.swtbot Secondly, all generic Sirius test helpers could be added in: * org.eclipse.sirius.sdk.test * org.eclipse.sirius.sdk.test.swtbot Thirdly, all other generic test helpers could be added in its dedicated test plugin. For example, tests/org.eclipse.sirius.ui.tests could contain several generic test helpers that will be only reused in the org.eclipse.sirius.ui.tests scope. These helpers haven't any vocations to be shared to other tests plugins. In deed, it will too hard to manage durably test dependencies. If an hepler need to be shared, it will be moved in sdk.test or sdk.test.swtbot. Created attachment 238271 [details]
Sample of test dependencies
Created attachment 238275 [details]
Sample of test dependencies
I add a missing dependency from sdk.test.swtbot to sdk.test. In deed, we can want to reuse the test contextualization already done in sdk.test to avoid code duplication.
|