Using lazy statics in #[tokio::test]

[naskya]

I’m using a static object that is initialized at runtime to manage a shared connection pool.

The code looks like the following. (this is more of a pseudocode; a minimal-ish working example using bb8 pool is https://github.com/naskya/connection-pool-test-example/blob/main/src/lib.rs)

Expand the code block

static CONNECTION_POOL: OnceCell<Pool> = OnceCell::const_new();

/// initializes the connection pool.
async fn init_pool() {
   CONNECTION_POOL.get_or_init(|| async { ... }).await;
}

/// acquires a connection from the pool.
async fn get_connection() -> Connection {
  if !CONNECTION_POOL.initilized() {
    init_pool().await;
  }

  CONNECTION_POOL.get().unwrap(). ... // get a connection out of the pool
}

/// does something using a connection.
async fn do_something() {
  let conn = get_connection().await;
  conn.some_operation();
}

Since #[tokio::test]s run independently and destroy the connection pool on exit, if I use the pool in unit tests, cargo test almost certainly fails, despite the code itself having no fault. However, if I cargo nextest run, it always succeeds (as far as I tested) thanks to the different execution method:

• https://github.com/naskya/connection-pool-test-example/actions/runs/9136555441/job/25125487558
• https://github.com/naskya/connection-pool-test-example/actions/runs/9136555441/job/25126182335
• https://github.com/naskya/connection-pool-test-example/actions/runs/9136555441/job/25126201743

Example output of cargo test and cargo nextest run

$ cargo test

    Finished test [unoptimized + debuginfo] target(s) in 0.03s
     Running unittests src/lib.rs (target/debug/deps/connection_pool_test_example-172912417ac1b1f3)

running 10 tests
test test::test_3 ... ok
test test::test_10 ... ok
test test::test_9 ... ok
test test::test_7 ... FAILED
test test::test_2 ... ok
test test::test_1 ... ok
test test::test_5 ... FAILED
test test::test_6 ... FAILED
test test::test_4 ... ok
test test::test_8 ... FAILED

failures:

---- test::test_7 stdout ----
thread 'test::test_7' panicked at src/lib.rs:122:64:
called `Result::unwrap()` on an `Err` value: broken pipe
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

and so on ...

$ cargo nextest run

    Finished test [unoptimized + debuginfo] target(s) in 0.05s
    Starting 10 tests across 1 binary (run ID: e6837a88-1b4a-43ec-a089-55510a0de4d4, nextest profile: default)
        PASS [   0.008s] connection-pool-test-example test::test_7
        PASS [   0.011s] connection-pool-test-example test::test_1
        PASS [   0.011s] connection-pool-test-example test::test_10
        PASS [   0.012s] connection-pool-test-example test::test_4
        PASS [   0.012s] connection-pool-test-example test::test_3
        PASS [   0.014s] connection-pool-test-example test::test_2
        PASS [   0.012s] connection-pool-test-example test::test_6
        PASS [   0.012s] connection-pool-test-example test::test_9
        PASS [   0.014s] connection-pool-test-example test::test_5
        PASS [   0.013s] connection-pool-test-example test::test_8
------------
     Summary [   0.017s] 10 tests run: 10 passed, 0 skipped

So, I think I want to use Nextest for this kind of unit test, but I wonder if this behavior is purely coincidental (i.e., there is no guarantee that I can use Nextest this way in the future) or if I can assume that this is one of the features.

Many thanks for creating/maintaining this project!

[sunshowers]

Thanks for the question!

Yes. Nextest guarantees in perpetuity that the default mode will always be process-per-test. (I strongly believe it is the right default.) If we add new ways of executing tests in the future, they'll always be behind an option.

[naskya]

Thanks for the clear answer!