[crate request] please give us a tempdir crate for use in tests

testing is "fun" (read: painful) especially it involves disk I/O but extra-especially if it involves Command. we'd really appreciate if there was a crate that made it easier to deal with all this stuff by making a tempdir or something.

ideally this would just be part of cargo test but sigh can't have nice things so w/e.

https://docs.rs/tempdir/0.3.7/tempdir/

... which is both deprecated and not intended for use with cargo test.

I've found the least annoying way to test sideeffectful code to be to separate the logic from the side effects as much as possible, and perform the side effects only in functions which are simple enough to not need their own tests.

If you want to test that a certain command gets executed in response to certain inputs, make the logic that creates the command and the argument return something that you can inspect, and test that. In the actual application, feed that through a simple mapping to the IO-performing functions from the standard library.

the whole point of writing things that don't rely on global state is that they don't rely on global state, and are thus easy to test.

this is easy to test. the problem is the testing tooling doesn't support it. there's no way to throw a separate chroot (or even a tempdir) at each test. in fact, there's never gonna be a way to use separate chroot because cargo test runs everything in threads, but again, no global state. makes things a lot easier, if you can just... ugh. >.<

we just wanna test that we're doing the thing with git that'll get git to do what we want it to do. because it's a lot easier to test individual parts (units) and know they're working than try to write the whole application and then only run integration tests by hand.

(and we can't use a git library because they don't support our git repos. they'll literally error out even tho git clone supports them fine.)

anyway uh, how can you get independent tempdirs for each #[test], and have them also be independent (and clean) across different cargo test?

we don't care that it's a bad idea to test this stuff, we're gonna test this stuff anyway.

What would be different about it if it was intended to be used with cargo test?

it'd be designed around the needs of something that runs in cargo test:

  • may be running from multiple threads, in a thread pool
  • wants independent empty dirs for each test
  • failure should keep things around
  • etc

assert_fs might fit the use-case.

1 Like

The tempdir crate is deprecated and has been replaced by tempfile. See the tempfile::tempdir() function.

You make a new call to tempdir() at the start of every test and use the TempDir it gives you to access its location. The directory will be automatically destroyed when the variable goes out of scope.

#[test]
fn check_foo() {
    let temp = tempfile::tempdir().unwrap();
    let temp_path = temp.path();

    ...
}