Invistigate integration tests current-thread runtime overloading

[jbesraa]

While working on setting up integration tests for the roles workspace, a concern about having too many [tokio::test] in a single test file have been raised by @Shourya742 here. While we are yet to hit any performance issue, mainly because we do not have much tests, this is a valid concern that should be kept in mind going forward.

[plebhash]

by default, tokio will spawn single threaded runtimes for functions marked with #[tokio::test], which could cause trouble for our integration tests

with regards to the number of threads some test would need (let's call it n_threads), we have basically two possible scenarios:

• we know n_threads beforehand
• n_threads is unknown until it is generated dynamically inside the test

known n_threads

this scenario can be easily solved via macro syntax.

for example, if we know beforehand that n_threads is 4:

#[tokio::test(flavor = "multi_thread", worker_threads = 4)]
async fn test_known_n_threads() { ... }

note that this is using tokio::test and async fn for the test function declaration.

unknown n_threads

for this scenario, the number of threads can be controlled dynamically with the following syntax:

#[test]
fn test_unknown_n_threads() {

    let n_threads = X; // this was determined dynamically

    let test_runtime = Builder::new_multi_thread()
        .worker_threads(n_threads) // Set the number of worker threads
        .enable_all() // Enables all Tokio features (e.g., time, I/O)
        .build()
        .expect("Failed to create custom runtime");

    test_runtime.block_on(async {
        // async integration tests here
    });
}

note that this is NOT using tokio::test nor async for the test function declaration.

---

P.S.: I'm not sure how realistic the "unknown n_threads" scenario is. I'm just brainstorming in a generalistic way.

maybe @Shourya742 or @jbesraa have more thoughts around this.