See https://github.com/colin-kiegel/rust-pretty-assertions/issues/85

Needing to assert on the results of HashMaps / HashSets is something I've needed to do quite often, so proposing this for inclusion in the crate.

This crate provides assert_eq_sorted!(), so won't conflict with the default pretty_assertions crate's override.

I've been working on some related code today (see e.g. https://github.com/ostreedev/ostree-rs-ext/pull/244 which is changing our test code there to use more cap-std bits and also trying to more carefully move the processes we fork off into per-test tempdirs).

And just glancing at your code, at least this call to set_current_dir() looks suspicious to me, because it looks like we're changing process global state in a proc macro.

What do you think of making tokio an optional dependency, enabled by default? I'd love to use assay for some tests that have nothing to do with tokio :)

This commit adds the ability to turn off async functionality by setting no-default-features = true in your Cargo.toml for assay. This means if you don't need the async functionality it won't bring in tokio by default reducing compile times. We also add support for async-std by setting no-default-features = true, features = ["async-std-runtime"] in your Cargo.toml for assay. Functionally this doesn't change how assay works and lets you choose another runtime for your code. Useful if you depend on functionality of a specific runtime. It has been orchestrated to make it easier to choose one of the two with feature flags while not breaking existing functionality.

Closes #8

I added this to leave open the possibility that in the future, nextest gains the ability to have multiple tests per process. See https://nexte.st/book/env-vars#environment-variables-nextest-sets for more information.

I have a test that roughly boils down to

#[assay]
async fn successfully_trigger_for_ci_job() {
    // Arrange
    let context = TestContext::start().await;

   ... a bunch of things...

    let status = response.status();
    let body = response
        .text()
        .await
        .unwrap();

    assay::assert_eq!(BodyAndStatus { body, status}, BodyAndStatus { body: "".to_string(), status: StatusCode::OK })
}

If I "break" the test by replacing the expected body, then the test output is just

where I'd expect to get a nice error based on pretty_assertions.

I don't see any feature flags or anything that I may have forgotten? Are there any constraints on how to use assay to get the pretty errors?

This PR adds a new argument ignore to the attribute macro, which expands into an #[ignore] attribute on the generated test function. A minimal test for this functionality is included, but no tests for the interaction with other arguments or features yet.

Additionally, this PR includes attributes specified on the input function in the generated test function. If you'd like, I can break this functionality out into its own PR.

With the second change, it should also be possible to remove the first change and deprecate the should_panic argument in favor of specifying #[ignore] or #[should_panic] directly.

Fixes #12

Assay currently parses things but any errors are a bit, well, lacking with information. It'd be nice if we could output diagnostics to the users so they can fix the issues rather than having a mostly subpar experience trying to get the syntax right OR signal an error in what they've done.

With the following code, I get an error when running tests with cargo test:

#[assay]
#[ignore]
fn fail() {
    panic!();
}

The output is:

$ cargo test
[...]
running 1 test
test fail ... FAILED

I expected the test to be ignored.

The equivalent code using #[test] does not cause a test failure.

#[test]
#[ignore]
fn fail() {
    panic!();
}

Cargo output:

$ cargo test
[...]
running 1 test
test fail ... ignored

Context

I was trying to run proptest tests under assay. Since they take a few seconds to run each, I was trying to ignore them, which is how I discovered the problem.

As discussed in #9, this PR changes the behaviour of the include attribute:

• #[assay(include = ["folder/my_file.rs"]) will copy the file into the root folder of the test working directory (i.e. file.rs);
• #[assay(include = [("folder/my_file.rs", "folder/my_renamed_file.rs"]) will instead use the specified destination path.

I have a few questions on the implementation that I've left as TODO comment in the code. I'd appreciate your input there.

Closes #9

I've been playing around with assay today for a side project and it has been 🔥

The only thing I am struggling with, right now, is including files. My project folder layout follows this structure:

src
  lib.rs
  module_with_tests.rs
  ...
  test_files
    test_name_1
      file_to_include_1
      ...

test_name_1 is a test that lives in module_with_tests.rs and I'd like to mount all files under test_files/test_name_1 in the temporary directory created for test_name_1. This doesn't seem possible at the moment based on my understanding of the docs. I can do:

    #[assay]
    #[assay(include = ["src/test_files/test_name_1/a_file_in_there.txt"])]
    fn test_name_1() {
        // [...]
    }

while what I want is

    #[assay]
    #[assay(include = [("src/test_files/test_name_1/a_file_in_there.txt", "a_file_in_there.txt"])]
    fn test_name_1() {
        // [...]
    }

Is there an easy layout that I could use to keep the files related to different tests separated? Would you be interested to support this functionality/review a PR for adding it?

Along the same lines, some kind of globbing would be quite handy - i.e. "mount all the files in this directory at the root of the temporary filesystem for the test".