dreltest

func Begin ¶

func Begin(t testingTB, engine *drel.Engine) *drel.Tx

Begin opens a transaction-scoped sandbox against a SQLite (or libSQL) engine: every write made through the returned *drel.Tx is rolled back when the test completes, giving per-test isolation without recreating the schema. Unlike a raw SAVEPOINT through the connection pool, this drives the engine's own single-connection transaction, so isolation holds for file-backed SQLite too (not just in-memory). Begin fails the test on a non-SQLite engine.

func CreateSchema ¶ added in v0.5.0

func CreateSchema(t testingTB, engine *drel.Engine, ddl ...string)

CreateSchema executes each DDL statement against the engine in order, failing the test on the first error. Convenience for tests that already hold an engine (it is the helper the PRD's hand-waved createSchema(t, engine) refers to).

func NewSQLite ¶

func NewSQLite(t testingTB, opts ...Option) *drel.Engine

NewSQLite creates an in-memory SQLite engine for testing, applying any options (WithMigrations, WithSchema, WithSeed) in that order. The engine is automatically closed when the test completes.

func WithRollback ¶ added in v0.6.0

func WithRollback(t testingTB, engine *drel.Engine, fn func(ctx context.Context))

WithRollback runs fn inside a transaction and rolls that transaction back. The transaction travels in the context, so code that calls Engine.WithTx joins it through a savepoint instead of opening its own transaction. Nothing fn writes reaches the next test.

Use it for every test that touches the database. On Postgres the test functions can then run in parallel against one database, and no test needs to recreate the schema.

func TestPlaceOrder(t *testing.T) {
    dreltest.WithRollback(t, engine, func(ctx context.Context) {
        err := service.PlaceOrder(ctx, order) // calls db.WithTx inside
        require.NoError(t, err)
    })
}

The rollback runs at test cleanup, so it also runs after t.Fatal. A failed test does not leak an open transaction.

Three limits hold.

A test that needs a second connection to read fn's writes cannot use WithRollback, because nothing is committed.

On Postgres the transaction holds one pooled connection for the whole test, so the pool must be larger than the count of parallel tests.

A SQLite engine drives one connection. Two parked transactions therefore cannot exist at one time, and two parallel WithRollback calls on one SQLite engine deadlock. Run the SQLite tests one after another, or give each test its own engine with NewSQLite.