6. Testing Plan¶
6.1. Re-verification scope¶
Before a pull request is merged, the full Ferrocene test suite is executed, which includes the tests for the core library. In addition, all release artifacts are built. As a result, no impact assessment is necessary.
6.2. Test workflow¶
Before running the tests, the changes are reviewed by an independent Ferrocene reviewer.
The tests are executed by the CI system, which also ensures that all tests succeed.
In case of a test failure, the change author will review the CI logs and fix the problem. The change will be reviewed again and the full test suite is executed again.
6.3. Test suites¶
6.3.1. Coretests¶
The core library is primarily tested by the coretests test suite. It defines the test case and pass/fail criteria.
Although only a subset of the core library is certified, also tests for uncertified functions are executed.
One example test is coretests::slice::test_position. It calls .position 4 times with different arguments and asserts that the results are correct:
1#[test]
2fn test_position() {
3 let b = [1, 2, 3, 5, 5];
4 assert_eq!(b.iter().position(|&v| v == 9), None);
5 assert_eq!(b.iter().position(|&v| v == 5), Some(3));
6 assert_eq!(b.iter().position(|&v| v == 3), Some(2));
7 assert_eq!(b.iter().position(|&v| v == 0), None);
8}
This test suite is executed on all qualified targets of Ferrocene.
The results of the coretests test suite can be found in the “Library Test Suite” section of each targets test results.
6.3.2. Doc-tests¶
Doc-tests are the code snippets in doc-comments. The doc-tests for the core library are executed as well. Note that doc-tests are not used for code coverage.
6.3.3. Code coverage tests¶
In order to gather code coverage information, an additional test run of the coretests test suite on the x86_64-unknown-linux-gnu target is performed.
It is ensured that both the instrumented and not instrumented coretests run succeeds. This ensures that coverage instrumentation does not introduce any correctness issues.
Code coverage is measured only on one platform, x86_64-unknown-linux-gnu. This is sufficient because the code of the core library is largely platform independent, and code coverage is only a measure of the quality of the test suite. Correctness is still tested by running the tests on all qualified targets.
How it works:
rustcis instructed to instrument the binary by passing-Cinstrument-coverage.The
coreteststest suite is executed. Due to the instrumentation, this will create.profrawfiles that contain the coverage information.symbol-reportis used to generate asymbol-report.jsonincluding all symbols in the certified subset and their spans.blanketis used to generate a HTML coverage report from the.profrawfiles, thesymbol-report.json, and the instrumented binaries.
6.3.3.1. Manual test coverage¶
If a line cannot be covered by automated tests it will be marked with a // Ferrocene annotation: REASON comment stating the reson. This annotation will be displayed in the generated HTML report.
6.3.4. Tidy test suite¶
The tidy test suite ensures conformance with syntax and semantic rules.
6.3.5. rustc lints¶
During compilation, rustc runs the borrow checker and executes a set of lints to ensure correctness, enforce consistency and prevent common errors.
6.3.6. Integration tests¶
The core library is heavily used in the other components of the Ferrocene toolchain, e.g. in rustc, the std library, rustdoc etc. The integration of the core library is tested by building and testing those components on all the supported platforms.