Name Description Size 0
browsers 1830 Context manager object that handles setup and teardown of a log queue for handling logging messages from wptserve. 13199
executors Path to the expectation data file for a given test path. This is defined as metadata_path + relative_test_path + .ini :param metadata_path: Path to the root of the metadata directory :param test_path: Relative path to the test file from the test root 472 This is basically a measure of the uniformity of the values in results based on the shannon entropy 4574 5566
formatters Instrumentation for measuring high-level time spent on various tasks inside the runner. This is lower fidelity than an actual profile, but allows custom data to be considered, so that we can see the time spent in specific tests and test directories. Instruments are intended to be used as context managers with the return value of __enter__ containing the user-facing API e.g. with Instrument(*args) as recording: recording.set(["init"]) do_init() recording.pause() for thread in test_threads: thread.start(recording, *args) for thread in test_threads: thread.join() recording.set(["teardown"]) # un-pauses the Instrument do_teardown() 4221 Manifest structure used to store expected results of a test. Each manifest file is represented by an ExpectedManifest that has one or more TestNode children, one per test in the manifest. Each TestNode has zero or more SubtestNode children, one for each known subtest of the test. 14787 Manifest structure used to store paths that should be included in a test run. The manifest is represented by a tree of IncludeManifest objects, the root representing the file and each subnode representing a subdirectory that should be included or excluded. 5492 Manifest structure used to update the expected results of a test Each manifest file is represented by an ExpectedManifest that has one or more TestNode children, one per test in the manifest. Each TestNode has zero or more SubtestNode children, one for each known subtest of the test. In these representations, conditionals expressions in the manifest are not evaluated upfront but stored as python functions to be evaluated at runtime. When a result for a test is to be updated set_result on the [Sub]TestNode is called to store the new result, alongside the existing conditional that result's run info matched, if any. Once all new results are known, update is called to compute the new set of results and conditionals. The AST of the underlying parsed manifest is updated with the changes, and the result is serialised to a file. 38830 A wrapper around RunInfo dicts so that they can be hashed by identity 34561 211
print_pdf_runner.html 965 Return tuple of (property_order, boolean_properties) indicating the run_info properties to use when constructing the expectation data for this product. None for either key indicates that the default keys appropriate for distinguishing based on platform will be used. 2420 Handler that filters out messages not of a given set of actions. Subclasses BaseHandler. :param inner: Handler to use for messages that pass this filter :param actions: List of actions for which to fire the handler 15847
testdriver-extra.js 12662
testdriver-vendor.js 38
testharness_runner.html 95
testharnessreport-content-shell.js 1946
testharnessreport-servo.js 604
testharnessreport-servodriver.js 866
testharnessreport-wktr.js 729
testharnessreport.js This function handles the next testdriver event. The presence of window.testdriver_callback is used as a switch; when that function is present we are able to handle the next event and when is is not present we must wait. Therefore to drive the event processing, this function must be called in two circumstances: Every time there is a new event that we may be able to handle Every time we set the callback function This function unsets the callback, so no further testdriver actions will be run until it is reset, which wptrunner does after it has completed handling the current action. 2434 Queue wrapper that is only used for writing items to a queue. Once all items are enqueued, call to_read() to get a reader for the queue. This will also prevent further writes using this writer. 27442 Class implementing the main loop for running tests. This class delegates the job of actually running a test to the executor that is passed in. :param logger: Structured logger :param command_queue: multiprocessing.Queue used to send commands to the process :param result_queue: multiprocessing.Queue used to send results to the parent TestRunnerManager process :param executor: TestExecutor object that will actually run a test. 44541
update 1954 Runner for web-platform-tests tests. 46546 Filter that replaces log messages at specified levels with messages at a different level. This can be used to e.g. downgrade log messages from ERROR to WARNING in some component where ERRORs are not critical. :param inner: Handler to use for messages that pass this filter :param from_levels: List of levels which should be affected :param to_level: Log level to set for the affected messages 3381
wptmanifest Runner for web-platform-tests The runner has several design goals: * Tests should run with no modification from upstream. * Tests should be regarded as "untrusted" so that errors, timeouts and even crashes in the tests can be handled without failing the entire test run. * For performance tests can be run in multiple browsers in parallel. The upstream repository has the facility for creating a test manifest in JSON format. This manifest is used directly to determine which tests exist. Local metadata files are used to store the expected test results. 25495 Override system info taken from the host if using an Android emulator. 24338