Jump to: navigation, search

Epsilon/Stable Version QA

< Epsilon
Revision as of 12:59, 7 October 2012 by Nyoescape.gmail.com (Talk | contribs) (Are the feature descriptions accurate, and do they work?)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Unlike interim releases, which are only required to pass their unit tests, stable releases should be manually tested on top of a clean copy of the latest stable Modelling distribution (Juno, at the time of this writing). Epsilon should be tested in the same way over the three target platforms: Windows, Mac OS X, and GNU/Linux. Since it's pretty much pure Java, the actual architecture (whether 32-bit or 64-bit) should not matter.

There are several questions that our manual testing should answer. We will describe how we can test for those below.

Can the features be installed?

Properly defined features declare all their dependencies, so we should be able to install each of them separately on top of a clean install. Eclipse should be able to automatically pick up other Epsilon features from the one we have selected.

If we have features A, B (depending on A) and C (depending on A) we should test that:

  1. Feature A can be installed from a clean install.
  2. By selecting feature B from a clean install, feature A will be picked up and install successfully as well.
  3. Same for feature C.

We might need to document additional dependencies for specific features. Some of these dependencies may have to be picked from external sources. We should provide the user with a suitable default choice.

Are the feature descriptions accurate, and do they work?

We need to ensure that each feature provides the expected functionality and no less. To do that, we can use the examples bundled with Epsilon: this will also serve as testing the documentation included with the release.

Here is a selection of examples, with the features they should be tested with and the actions to be performed with them:

  • emc.dummydriver: core. Should only require running the DummyModel class as a standalone Java application.
  • eugenia.examples.fed: GMF tooling, eugenia (generation from .ecore + execution).
  • eugenia.examples.friends: GMF tooling, Emfatic, eugenia (generation from .emf + execution, to launch its EGL script from "Sample Menu > Call EGL").
  • eugenia.examples.filesystem: GMF tooling, eugenia, evl.emf (generation + validation from GMF). Creating a few unnamed drives and saving should trigger validation and report several errors.
  • eugenia.examples.flowchart: GMF tooling, eugenia, evl.emf, ewl.gmf (generation + execution). We should create a diagram and check the custom figures for the action and decision nodes. Then, we should create a Decision with no outgoing edges and use "Edit > Validate" to detect that it should have two or more edges. Finally, we should fix the problem using the EWL wizard that creates the yes-no transitions.
  • eunit.examples.atl: ATL, emf.dt. Just run the "Test Tree2Grap" stored launch configuration.
  • eunit.examples.egl.files, eunit.examples.etl: hutn, emf.dt.
  • eunit.examples.* (the rest): emf.dt. Running the Ant tasks should cover the workflow and the E*L engine as well.
  • buildooinstance: emf.dt to run. core.dt to edit the .eol files.
  • evl.ecore: evl.emf.
  • ewl.ecore: ewl.emf.
  • hutn.families: hutn.dt provides the project builder that generates the Demo model automatically from the HUTN source.

We still need an example to test the Concordance feature, though.

Note: as of 1.0RC4 (2012-10-07), the Eugenia feature requires installing the GMF Tooling separately. It's not picked up from the feature dependencies.