fix(sqlite): apply drivers.sqlite config from sqlx.toml in #[sqlx::test]

[jdscreations]

Does your PR solve an issue?

fixes #4372

Is this a breaking change?

No — this brings #[sqlx::test] in line with the already-documented behavior of drivers.sqlite in sqlx.toml, which sqlx::query!() and sqlx-cli already apply. Strictly speaking, per Hyrum's Law, a project with drivers.sqlite config in its sqlx.toml that happened to rely on #[sqlx::test] not applying it could see a behavior change, but that would be relying on an unintentional gap rather than documented behavior.

Summary

#[sqlx::test] didn't apply drivers.sqlite config from sqlx.toml (e.g. unsafe-load-extensions) to the SQLite databases it creates, unlike connections made through sqlx::query!() or sqlx-cli, which already read this configuration via SqliteConnectOptions::apply_driver_config(). A project using SQLite extensions in its migrations (as supported since #3917) would have those migrations fail inside #[sqlx::test], because the extension was never loaded.

Root cause

test_context() in sqlx-sqlite/src/testing/mod.rs built SqliteConnectOptions directly:

SqliteConnectOptions::new()
    .filename(&db_path)
    .create_if_missing(true)

without ever calling .apply_driver_config(&config.drivers.sqlite), so any drivers.sqlite settings in sqlx.toml were silently ignored for test databases.

Approach

Added apply_sqlx_toml_config(), which reads Config::try_from_crate_or_default() and applies config.drivers.sqlite via the existing apply_driver_config(), and call it when building the options in test_context(). This is the same config-reading path already used by sqlx-sqlite::describe_blocking (for sqlx::query!()/sqlx-cli), just applied to the test-database path too.

I considered inlining the two new lines directly into test_context() (which is what the fix boiled down to), but extracting them into a small synchronous helper made it possible to unit test the config-application logic in isolation, without needing an async runtime.

Test evidence

Added sqlx-sqlite/sqlx.toml (used only by this new test) with a bogus unsafe-load-extensions marker entry, and a unit test in sqlx-sqlite/src/testing/mod.rs:

Before the fix (verified by temporarily reverting apply_sqlx_toml_config() to a no-op):

running 2 tests
test testing::test_convert_path ... ok
test testing::test_context_applies_sqlx_toml_driver_config ... FAILED

---- testing::test_context_applies_sqlx_toml_driver_config stdout ----
thread '...' panicked at sqlx-sqlite/src/testing/mod.rs:113:5:
expected `unsafe-load-extensions` from sqlx-sqlite/sqlx.toml to be applied, got: {}

After the fix:

running 2 tests
test testing::test_convert_path ... ok
test testing::test_context_applies_sqlx_toml_driver_config ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 7 filtered out

Also ran, all passing with no regressions:

• cargo test -p sqlx-sqlite --features migrate,sqlx-toml --lib (9/9 passed)
• cargo test --test sqlite-test-attr --no-default-features --features "sqlite,macros,migrate,runtime-tokio,tls-none" — the existing end-to-end #[sqlx::test] suite (5/5 passed), confirming no change in behavior for projects without drivers.sqlite config in their sqlx.toml
• cargo clippy -p sqlx-sqlite --features migrate,sqlx-toml --lib --tests — clean
• cargo fmt -p sqlx-sqlite -- --check — clean

Note: I don't have Docker/Postgres/MySQL available in my environment, so I was only able to run the SQLite-specific suites above; this change only touches sqlx-sqlite.