`#[sqlx::test]` manage the full lifecycle of the test DB (inside a container)

[Zizico2]

Describe the solution you'd like Have #[sqlx::test] manage the full lifecycle of the test DB. Currently I'm running my tests using test-containers, so I don't need any externally setup DB. Would this be something that could be incorporated into SQLx itself? Currently I'm using regular #[tokio::test].

Describe alternatives you've considered Have some way to run a setup function, before whatever #[sqlx::test] is doing. This way I could setup the container and maybe set the DATABASE_URL environment variable. It could look like #[sqlx::test(setup=my_setup_function)].

[nk9]

I would also like to use test containers with my SQLx code, so being able to define a fixture to set up the environment before running each test would be great.

[nk9]

This seems to be a duplicate of #3022.

[Zizico2]

I guess not exactly since I propose the direct integration of test-containers

[abonander]

At a certain point we're just talking about a completely different implementation of test harness here.

Because testcontainers stops the container on-drop, you couldn't just start it in a setup function. You'd need a way to retain ownership of it for the duration of the test. Or you'd need to forget() it and have a separate teardown function to delete the container at the end, and then some way to thread the container ID past the test function (I suppose a thread-local would work).

This could be integrated as an optional feature, but I'm wary of maintaining essentially two completely separate execution strategies for tests. And I don't want to make it the primary execution strategy because it requires having Docker installed, which not everyone wants to do or is able to do because of how it's licensed and the additional requirements on non-Linux platforms. And it doesn't look like testcontainers supports alternate container frontends like Podman.

Ultimately, this concept should probably live in its own crate.