Getting started with Allure Diesel

Record executed Diesel queries as steps in your Allure Report test reports. It hooks into Diesel's Instrumentation API, so it's wired up once in test or setup code and never touches production query call sites.

allure-diesel records against whichever Allure context is bound to the current thread when a query runs — the same thread-bound context Rust Cargo Test sets up automatically inside #[allure_test]. Outside an active Allure context (for example, in application code, or in tests that don't use #[allure_test]), every instrumentation event is a silent no-op — nothing is recorded and nothing fails.

INFO

The official allure-rust repository also publishes allure-reqwest for capturing reqwest HTTP calls as Allure attachments.

Setting up

1. Make sure you have an Allure integration set up for your test runner. See Rust Cargo Test.

2. Add the dependency:

   cargo add allure-diesel --dev

3. Attach the instrumentation. Two ways to do it:

   Per connection — attach it right after establishing each connection you want captured:

   use diesel::prelude::*;
   use diesel::sqlite::SqliteConnection;
   
   fn connect() -> ConnectionResult<SqliteConnection> {
       let mut conn = SqliteConnection::establish(":memory:")?;
       conn.set_instrumentation(allure_diesel::AllureInstrumentation::new());
       Ok(conn)
   }

   Globally — register it once during test setup, and every connection established afterward in the process is captured with no call-site changes:

   fn setup() -> diesel::QueryResult<()> {
       allure_diesel::install_default()
   }

4. Run your tests and generate a report the same way as you would normally — see Rust Cargo Test.

What gets captured

• Each executed statement becomes a step named after its rendered SQL (see Reference for how long statements are shortened), and by default carries the full SQL as a nested query.sql attachment step.
• BEGIN/COMMIT/ROLLBACK boundaries become a transaction step that nests the queries run inside that transaction, including the boundary statements themselves. See Reference for exactly how nesting and failure are represented.
• A query that returns a database error marks its step (and, for a failing transaction boundary, the enclosing transaction step) failed, with the Diesel error message.

What's not captured

Diesel's instrumentation exposes the SQL of each statement but not the rows a query returns — no non-invasive Diesel hook does. This crate therefore records queries and transactions, not result sets.

WARNING

There is no redaction. The recorded SQL — in both the step name and the query.sql attachment — can include bind values exactly as Diesel renders them (for example, via a -- binds: [...] comment on parameterized queries), so a captured statement can contain the same sensitive data your query was parameterized to avoid logging in plain text. Keep this in mind before publishing reports built from tests that touch real data.