#error #error-handling #points

dev testresult

Provides TestResult type for concise and precise test failures

4 releases (breaking)

0.4.0 Mar 14, 2024
0.3.0 Feb 2, 2023
0.2.0 Jan 10, 2023
0.1.0 Oct 12, 2022

#121 in Rust patterns

Download history 399/week @ 2024-01-05 526/week @ 2024-01-12 634/week @ 2024-01-19 436/week @ 2024-01-26 593/week @ 2024-02-02 773/week @ 2024-02-09 548/week @ 2024-02-16 685/week @ 2024-02-23 527/week @ 2024-03-01 523/week @ 2024-03-08 752/week @ 2024-03-15 920/week @ 2024-03-22 631/week @ 2024-03-29 1157/week @ 2024-04-05 1693/week @ 2024-04-12 1425/week @ 2024-04-19

5,114 downloads per month
Used in 23 crates (21 directly)

MIT/Apache

10KB
73 lines

Test result

CI Crates.io Codecov

Provides TestResult type that can be used in tests to avoid unwraps but at the same time to have precise stacktraces with the point of failure clearly written.

It's like a lean anyhow for tests!

Details

Consider the following code. It uses unwrap so the test failure stacktrace will informative. Unfortunately it's not as concise as it could be:

#[test]
fn it_works() {
   // ...
   std::fs::File::open("this-file-does-not-exist").unwrap();
   // ...
}

Improved version of this code uses Result and the ? operator:

#[test]
fn it_works() -> Result<(), Box<dyn std::error::Error>> {
   // ...
   std::fs::File::open("this-file-does-not-exist")?;
   // ...
   Ok(())
}

Running the following code with RUST_BACKTRACE=1 cargo test shows the following stacktrace:

---- tests::it_works stdout ----
thread 'tests::it_works' panicked at 'assertion failed: `(left == right)`
  left: `1`,
  ...
   4: test::assert_test_result
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/test/src/lib.rs:184:5
   5: testresult::tests::it_works::{{closure}}
             at ./src/lib.rs:52:5
   6: core::ops::function::FnOnce::call_once
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/ops/function.rs:248:5
  ...
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Unfortunately even though the test function location is recorded, the exact line where the test failure occurred is not present in the backtrace.

Let's adjust the test result type to use TestResult. This is the only change compared to previous example:

#[test]
fn it_works() -> TestResult {
   // ...
   std::fs::File::open("this-file-does-not-exist")?;
   // ...
   Ok(())
}

Running it again with cargo test shows more details:

---- tests::it_works stdout ----
thread 'tests::it_works' panicked at 'error: std::io::error::Error - No such file or directory (os error 2)', src/lib.rs:53:9

Note that the error location is now in the backtrace and also in the test failure message. This means that we don't even need the backtrace to know where the error happened.

The advantages of using TestResult:

  • exact failure line is present in the test failure and the backtrace,
  • the underlying error type and message are present in the test failure,
  • the signature of the test result is simpler.

For a more elaborate description see "Improving failure messages in Rust tests returning a Result".

License

This project is licensed under either of:

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this crate by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

No runtime deps