947
edits
Projects/ManifestDestiny/Integration: Difference between revisions
Jump to navigation
Jump to search
Projects/ManifestDestiny/Integration (view source)
Revision as of 00:08, 30 June 2011
, 30 June 2011→How they work together: even more formatting
(→How they work together: more formatting) |
(→How they work together: even more formatting) |
||
| Line 46: | Line 46: | ||
. manifestparser contains two classes for handling .ini manifests: | . manifestparser contains two classes for handling .ini manifests: | ||
* ManifestParser contains the basic logic for parsing ordered | * ManifestParser contains the basic logic for parsing ordered and nested manifests as well as querying them based on their tags. ManifestParser is not specific to tests | ||
and nested manifests as well as querying them based on their | |||
tags. ManifestParser is not specific to tests | |||
* TestManifest inherits from ManifestParser and is the integration | * TestManifest inherits from ManifestParser and is the integration layer for test harnesses. | ||
layer for test harnesses. | |||
The tests are returned as a list of dicts, with some keys, such as the | The tests are returned as a list of dicts, with some keys, such as the | ||
| Line 63: | Line 60: | ||
special keys in the test dict. Currently, there are: | special keys in the test dict. Currently, there are: | ||
* skip-if: mark the test as ``disabled`` if the condition given as the | * skip-if: mark the test as ``disabled`` if the condition given as the value of the key is true. The variables passed in are used with basic javascript-syntax boolean logic (e.g.):: | ||
value of the key is true. The variables passed in are used with | |||
basic javascript-syntax boolean logic (e.g.):: | |||
skip-if = os == 'linux' || (toolkit == 'cocoa' && debug) | skip-if = os == 'linux' || (toolkit == 'cocoa' && debug) | ||
| Line 72: | Line 67: | ||
should be passed into the ``active_tests`` method. | should be passed into the ``active_tests`` method. | ||
* run-if: similar to skip-if, but mark the test as ``disabled`` if the | * run-if: similar to skip-if, but mark the test as ``disabled`` if the condition is not true. skip-if and run-if can be used together, but if either disables the test, the test is disabled. | ||
condition is not true. skip-if and run-if can be used together, but | |||
if either disables the test, the test is disabled. | |||
* fail-if: the ``expected`` value of tests returned from | * fail-if: the ``expected`` value of tests returned from ``active_tests`` is ``pass`` unless specified otherwise in the .ini file. If the test for fail-if is true, however, the value of ``expected`` will be ``fail``. | ||
``active_tests`` is ``pass`` unless specified otherwise in the .ini | |||
file. If the test for fail-if is true, however, the value of | |||
``expected`` will be ``fail``. | |||
It is up to the harness to treat the tests appropriately based on | It is up to the harness to treat the tests appropriately based on | ||
| Line 119: | Line 109: | ||
* mozinfo introspects system information | * mozinfo introspects system information | ||
* the mozinfo information may be augmented or overridden from the | * the mozinfo information may be augmented or overridden from the build information as output by writemozinfo | ||
* the mozinfo information may be fed into | * the mozinfo information may be fed into ``TestManifest.active_tests`` to retrieve a properly marked-up list of tests | ||
* test harnesses and other consumers have several degrees of freedom | * test harnesses and other consumers have several degrees of freedom to customize how things fit together | ||