Specifying a mock DB at runtime and ensuring graceful Local Rocket shutdown w/ tests

[raif-s-naffah]

hello there,

i'm using a Local Rocket w/ a blocking Client for testing. i also use a mock DB that is created at the start of each test (specifically when Rocket is built) and dropped at the end of said test.

the mock DB and its pool are created using my own Fairing implementation that most likely is similar to how rocket_db_pools does its job. the difference is that i set the database connection URL at runtime allowing me to do the work when calling the build() method which now has a boolean argument that tells whether to use a mock DB or not.

q1/ is there a way to do the same or better w/ existing Rocket capabilities?

using a local Client also means that to cause a graceful Rocket shutdown i have to call the terminate() method on said Client. the shutdown here is needed to trigger the fairing shutdown hook to drop the mock DB if one was used.

q2/ is it possible to trigger a Rocket shutdown when a Client instance is dropped?

finally, to ensure the terminate() method is called on the Client whether a test succeeds or not, i use unwind_safe ¹. a typical test would then look like so...

use rocket::local::blocking::Client;

#[test]
fn test_xxx(client: &mut Client) -> Result<()> {
    let rocket = server::build_it(true);
    let client = Client::tracked(rocket).unwrap();
    let result = {
        ::unwind_safe::with_state::<Client>(client)
            .try_eval(|client| {
                /* test statements... */
            })
            .finally(|client: Client| {
                let _ = client.terminate();
            })
    };
    result
}

(server above is module that contains the build(bool) method and other logic to wire and return the Rocket<Build> instance to launch).

q3/ is there a [better] way of doing this w/ existing Rocket capabilities.

thanks in advance for any answers, suggestions, and comments (especially for q3) + cheers;

Footnotes

1. https://crates.io/crates/unwind_safe ↩

[SergioBenitez]

q1/ is there a way to do the same or better w/ existing Rocket capabilities?

You can config databases at runtime with rocket_db_pools as well. It's documented in [Config].

is it possible to trigger a Rocket shutdown when a Client instance is dropped?

No. This is a restriction imposed by Rust and tokio. For async clients, we'd need async Drop, which doesn't exist.

q3/ is there a [better] way of doing this w/ existing Rocket capabilities.

Not with Rocket directly, but I would advocate for either using a more advanced unit testing library that offers set-up and tear-down (like test-context), or if you're only going to be using the blocking Client, you could consider a wrapper with a Drop impl that calls terminate:

struct Client(Option<rocket::local::blocking::Client>);

impl Drop for Client {
    fn drop(&mut self) {
        self.0.take().unwrap().terminate();
    }

}

[raif-s-naffah]

thanks Sergio for your prompt reply + suggestions.

test-context works nicely and ensures the client is terminated properly and Rocket shutdown gracefully.

i'm trying to use rocket_db_pools but i'm hitting a wall. i'm able to configure a mock DB at the startup of a test and merge its Config w/ Rocket's fine; however i'm unable to run the migrations on that DB w/ an AdHoc::try_on_ignite hook similar to what this example does.

at first look it seems i cannot derive a mock Database (w/ a random name at runtime) so i can then init() and fetch() it in AdHoc hooks in order to apply the migrations.

am i missing something obvious?

thanks again for your time.

[raif-s-naffah]

i had a closer look at the rocket_db_pool crate and while it's true i can configure a name and connection pool options for an ephemeral DB to use for testing w/ Config as was pointed out; w/o implementing at least the Database and may be Pool traits i found it hard to...

• create a (PostgreSQL) database,
• apply the same migrations as the production one,
• drop the database.

it would be nice if such a facility is made available in the future, may be building on Figment's notion of Profiles.