JohnstonJ
commented
3 weeks ago Here's an updated workaround I came up with. It solves the problem of somebody forgetting to add a #[case] attribute by moving all the test cases into a single HashMap, and then adding a test case that asserts that every map entry has a corresponding test in the test binary.
Updated workaround
```rust use core::str; use std::{ collections::{HashMap, HashSet}, ops, path::PathBuf, sync::LazyLock, }; use derive_more::{Deref, From}; use googletest::prelude::*; use regex::Regex; /// Directory containing test-related data files. pub(crate) fn test_resource(path: &str) -> PathBuf { [env!("CARGO_MANIFEST_DIR"), "resources/test", path].iter().collect() } /// Map of test case name to test case data. See the [`test_case_map`] macro for an example of how /// to use this. #[derive(Debug, Deref, From)] pub(crate) struct TestCaseMap<'a, T>(HashMap<&'a str, T>); impl<'a, T> TestCaseMap<'a, T> { /// Return test case given the test function name generated by rstest /// /// The parameter needs to be the return value of the [`stdext::function_name`] macro. The /// macro must be called from within a `#[case]` attribute. Do not call it from within your /// test function itself. /// /// Example input: `my_crate_name::my_module::tests::test_frob::case_1_success_if_foo` which /// will return `success`. pub(crate) fn get_test_case(&self, test_function_name: &'a str) -> &T { let case_name = &GET_TEST_CASE_RE.captures(test_function_name).unwrap()[1]; assert!(self.contains_key(case_name), "Test case {case_name} is not in test table"); &self[case_name] } } /// A lazy-initialized map of test cases. See the [`test_case_map`] macro for an example of how to /// use this. pub(crate) type LazyTestCases<'a, T> = LazyLockThe test_case_map macro has an example that shows how to use it.
I don't particularly love this solution, but I haven't been able to think of a better way. It makes some assumptions about the output of the test binary when using --list, it has to invoke the test binary in the first place, it makes some assumptions about the naming convention of the rstest-generated code, and the function_name! macro that was used makes some assumptions about how Rust returns this string.
Potentially rstest could generate more code that reduces/eliminates the need for some of these assumptions, but then again it would also be adding new public APIs for what amounts to a rustfmt workaround, so not sure if it's worth it.
For example, rstest could provide an automatic "test case name" fixture so I don't have to call function_name!. It could also provide a fixture for the name of the test itself. (Something that seems to be a common request but hasn't yet been implemented by Rust's testing infrastructure - no good solutions to get at runtime. But rstest, being a macro, can easily discover the test name during parsing.) It could also emit a static variable that contains the list of all test cases for the test (names of generated test functions).
la10736
TL;DR: I want my test case inputs into rstest to be auto-reformatted with rustfmt, and this is proving surprisingly hard to figure out a way to do this without introducing other downsides like the possibility of forgetting to run a test case.
I have some more complicated test case inputs, and I'm struggling to figure out how to use
rstestso that they are automatically formatted by rustfmt. Is it even possible in a reasonable way? If not, I wonder if there may be some solutions possible to make the situation better.Currently, it seems that anything inside of
#[case::panic(42, "Foo")]is not reformatted by rustfmt, and this can get quite messy if we are passing in a lot of parameters and/or complex structs.The best workaround I've come up with is to put each test case into its own separate variable, and reference the variables. Here is an example:
Click to view example
```rust #[derive(Debug)] struct InfoCheckSimilarTestCase<'a> { expected: Info, comparison: Info, err: Option<&'a str>, } static INFO_CHECK_SIMILAR_MATCHES: LazyLockWhile this does restore the ability to format the complex test cases with rustfmt because at this point they are simple static variables, this workaround has several downsides:
#[case(...)], then the test case is not run!Ideally, there would be a way to have
#[rstest]consume a list of test cases from someplace else? But I haven't been able to figure out how to do that. The matrix / list input testing functionality still seems to demand a hard-coded list, which still leaves opportunity for somebody to forget to add new test case variables to the rstest matrix.Key things I'm looking for:
Past experiences in other languages:
casesyntax, Python's black reformatter has no problem with reformatting code inside a decorator. So I put the test case structures directly inside of the decorator, similar to the rstest examples in the documentation.In comparison, this is proving surprisingly hard for me to figure out how best to do this in Rust...