Crate deqp_runner
source ·Expand description
deqp_runner consists of this library crate for supporting parallel testing of various test suites (dEQP, piglit, gtest, IGT GPU Tools) using baseline expectations plus known flakes, plus several binary commands for invoking this library.
Adding a new test suite should be a matter of:
- Add a
parse_testsuite
module for parsing the output of your test suite and turning it into a TestStatus. - Add a
testsuite_command
module implementing TestCommand for invoking your test suite. - Add at least one of:
bin/testsuite.rs
binary to call parallel_test on your TestCommand.bin/deqp.rs
support to read a description of your to run your testsuite from asuite.toml
file and generate test groups for it along with the other testsuites inSuiteConfig
. This is useful if a user would want to run your testsuite along with others all at once with one summary at the end.
- Probably:
- Add a
mock
subcommand in your bin/testsuite.rs that pretends to be your testsuite binary (for integration testing without having the testsuite installed) with whatever interesting behaviors your testsuite has you might want to test (timeouts, crashes, flakiness). tests/integration/testsuite_runner.rs
module to test calling yourbin/testsuite.rs
command, passing in testsuite.rs’s built binary path as the testsuite to call with the Mock subcommand.
- Add a
Modules§
- Module for invoking VK-GL-CTS (aka dEQP) tests.
- Module for running fluster tests.
- Module for invoking googletest tests.
- Module for invoking IGT GPU Tools tests.
- Parses the output of OpenCL CTS test binaries into a deqp-runner status
- Module for invoking piglit tests.
Structs§
- TestCase struct for test commands where each test is a separate binary and set of args.
- The collection of results from invoking a binary to run a bunch of tests (or parsing an old results.csv back off disk).
- A test result entry in a CaselistResult from running a group of tests
Enums§
- The result types logged to the console: like TestStatus but with
ExpectedFail
(yeah, it failed, but you knew it failed in the baseline anyway and weren’t expecting to have fixed it) andUnexpectedImprovement
(congrats, you’ve fixed a test, go clear the xfail out of your baseline!). - Some TestCommand implementations need more than a string test name to invoke their test binary. All of those variants are in this enum so that the core parallel_test can talk about lists of TestCases, while the specific TestCommand implementation can match the subtype out to get at the test’s details.
- Enum for the basic types of test result that we track
Traits§
- trait for TestCommands that run a single BinaryTest per test group.
- trait for TestCommands that run a single TestCase::Named() per test group.
- trait for TestCommands that run a single test per test group.
- This is implemented by each supported test suite.
Functions§
- The heart of deqp-runner: this distributes the list of test groups (each a TestCommand and list of tests to run an invocation of that command) to the thread pool to parallelize running them across cores, collecting the results to the RunnerResults and logging incremental status to the console along the way.
- Parses a deqp-runner regex set list, used for the skips/flakes lists that the user specifies. We ignore empty lines and lines starting with “#”, so you can keep notes about why tests are disabled or flaky.
- Called with the results of a parallel_test, this outputs the
results.csv
(all results with timings) and thefailures.csv
(unexpected results for the user the user needs to debug, or to use as their--baseline
for future regression testing). Also prints a summary of failures, flakes, and runtimes for management of test runs. - Reads in the
--baseline
argument of expected-failing tests. Baselines are of the same format as afailures.csv
so you can use your first run as the baseline for future runs. - Common helper for reading the lines of a caselist/baseline/skips/flakes file, producing useful error context.
- Returns the thread index, used in various TestCommand implementations to have separate paths per thread to avoid races between tests being run in parallel.