Crates.io | dylint_testing |
lib.rs | dylint_testing |
version | 3.2.1 |
source | src |
created_at | 2021-03-25 18:03:30.004284 |
updated_at | 2024-10-07 16:53:08.855662 |
description | Utilities for testing Dylint libraries |
homepage | |
repository | https://github.com/trailofbits/dylint |
max_upload_size | |
id | 373501 |
size | 29,215 |
This crate provides convenient access to the compiletest_rs
package for testing Dylint
libraries.
Note: If your test has dependencies, you must use ui_test_example
or ui_test_examples
.
See the question_mark_in_expression
example in this repository.
This crate provides the following three functions:
ui_test
- test a library on all source files in a directoryui_test_example
- test a library on one example targetui_test_examples
- test a library on all example targetsFor most situations, you can add the following to your library's lib.rs
file:
#[test]
fn ui() {
dylint_testing::ui_test(env!("CARGO_PKG_NAME"), "ui");
}
And include one or more .rs
and .stderr
files in a ui
directory alongside your library's
src
directory. See the examples in this repository.
In addition to the above three functions, ui::Test
is a test "builder." Currently, the main
advantage of using Test
over the above functions is that Test
allows flags to be passed to
rustc
. For an example of its use, see non_thread_safe_call_in_test
in this repository.
Test
has three constructors, which correspond to the above three functions as follows:
ui::Test::src_base
<-> ui_test
ui::Test::example
<-> ui_test_example
ui::Test::examples
<-> ui_test_examples
In each case, the constructor's arguments are exactly those of the corresponding function.
A Test
instance has the following methods:
dylint_toml
- set the dylint.toml
file's contents (for testing configurable libraries)rustc_flags
- pass flags to the compiler when running the testrun
- run the test.stderr
filesIf the standard error that results from running your .rs
file differs from the contents of
your .stderr
file, compiletest_rs
will produce a report like the following:
diff of stderr:
error: calling `std::env::set_var` in a test could affect the outcome of other tests
--> $DIR/main.rs:8:5
|
LL | std::env::set_var("KEY", "VALUE");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: `-D non-thread-safe-call-in-test` implied by `-D warnings`
-error: aborting due to previous error
+error: calling `std::env::set_var` in a test could affect the outcome of other tests
+ --> $DIR/main.rs:23:9
+ |
+LL | std::env::set_var("KEY", "VALUE");
+ | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+error: aborting due to 2 previous errors
The actual stderr differed from the expected stderr.
Actual stderr saved to ...
The meaning of each line is as follows:
+
) is in the actual standard error, but not in your .stderr
file.-
) is in your .stderr
file, but not in the actual standard
error.
) is in both the actual standard error and your .stderr
file, and is provided for context.diff of stderr:
) contain compiletest_rs
messages.Note: In the actual standard error, a blank line usually follows the error: aborting due to N previous errors
line. So a correct .stderr
file will typically contain one blank line at
the end.
In general, it is not too hard to update a .stderr
file by hand. However, the compiletest_rs
report should contain a line of the form Actual stderr saved to PATH
. Copying PATH
to your
.stderr
file should update it completely.
Additional documentation on compiletest_rs
can be found in its repository.