Auto-tools/Projects/ManifestDestiny
OBSELETE: ManifestDestiny documentation now lives at https://mozbase.readthedocs.org/en/latest/manifestdestiny.html . Information on this page should be moved there (see https://wiki.mozilla.org/Auto-tools/Projects/MozBase/WritingDocs ) and this page removed
ManifestDestiny
ManifestDestiny is software for reading test manifests in a proposed .ini file format. The source code is available at https://github.com/mozilla/mozbase/tree/master/manifestdestiny. The canonical documentation lives at https://github.com/mozilla/mozbase/blob/master/manifestdestiny/README.md which should be consulted for up-to-date and more thorough documentation. This wiki page just serves as a convenience stub.
The main objective of ManifestDestiny, or UniversalManifests in general, is to allow arbitrary key, value annotations on tests or groups of tests. While the annotations are arbitrary to the parser, an integration layer (either at the harness level or more generically) uses agreed upon convention to determine e.g. what tests to run depending on harness invocation. Keeping the logic out of the manifests and in the integration layer(s) allows a universal format for manifests, a shared body of code to parse these, and some shared code for the integration layer. In addition, manifests are kept clean and readable.
ManifestDestiny is part of the MozBase effort.
File Format
Tests represented as sections in the .ini files. A simple test containing one file, 'aTest.js' would look like:
[aTest.js]
Usually (in all existing cases), the section name (aTest.js) is the relative path to the test file or directory. This is currently loosely assumed in the parser. Tests may have arbitrary key, value metadata associated with them:
[aTest.js] foo = bar disabled =
While the .ini file is a de facto standard ( http://en.wikipedia.org/wiki/INI_file ) that usually represents an unordered data structure, it is desirable to run the tests in the order presented in the file. ManifestDestiny follows this ordered convention.
Additional manifest files may be included with a include: directive:
[include:path-to-additional-file.manifest]
The path to included files is relative to the current manifest. The included file will inherit all top-level variables of the manifest its included from and whatever overrides it specifies in its own section.
The DEFAULT section contains variables that all tests in the current and included manifest inherits from. Tests may override top-level variable by their own sections.
The internal format of the tests is (in python terms) a list of dicts:
[{'path': '/home/jhammel/mozmill/src/ManifestDestiny/manifestdestiny/tests/testTechnicalTools/testAccessPageInfoDialog.js', 'name': 'testTechnicalTools/testAccessPageInfoDialog.js', 'here': '/home/jhammel/mozmill/src/ManifestDestiny/manifestdestiny/tests', 'manifest': 'tests/mozmill-example.ini'}, {'path': '/home/jhammel/mozmill/src/ManifestDestiny/manifestdestiny/tests/testToolbar/testBackForwardButtons.js', 'name': 'testToolbar/testBackForwardButtons.js', 'here': '/home/jhammel/mozmill/src/ManifestDestiny/manifestdestiny/tests', 'manifest': 'tests/mozmill-example.ini'}]
As long as this internal format is kept, the internal logic can be maintained independently of manifest format
Architecture
ManifestDestiny uses a two-tiered architecture:
- a manifest parser, that will read the tests into the appropriate data structure from the .ini manifests
- a generic integration layer, that will make harness-agnostic conventions functional (e.g. disabling according to operating-system type).
In addition, a harness may (optionally) have a harness-specific integration layer to make use of conventions appropriate only for that test type.
The integration layers contain the logic to turn convention into functionality.
Usage
ManifestDestiny in use:
Mozmill: https://bugzilla.mozilla.org/show_bug.cgi?id=585106
xpcshell: https://bugzilla.mozilla.org/show_bug.cgi?id=616999
Integration with Mozinfo
See Projects/ManifestDestiny/Integration
Contact
Talk to jhammel or jmaher on the #ateam channel for feedback or issues, or mail jhammel at mozilla dot org.