Lesson 8 · Mocks & mock generation

Mocking the database

The hardest collaborator to fake — and the house toolkit that fakes pgx so completely a repository needs no real Postgres.

Your win: mock the database at two levels — the transaction interfaces for a usecase, and the full pgx driver (via testutil.MockDB) for a repository — and explain the reflection trick that fakes Scan.

Two levels, because the database appears twice

A usecase uses the database through database.Ext/Tx (to run a transaction); a repository is the thing that talks to pgx. So you mock at two different depths:

Level 1 — the transaction (usecase test)

You saw this in Lesson 6. The handler opens a transaction and commits; you mock exactly that:

mockDB := new(mock_database.Ext)                // the pool interface
mockTx := new(mock_database.Tx)                 // the transaction interface
mockDB.On("Begin", ctx).Return(mockTx, nil)   // db.Begin() → tx
mockTx.On("Commit", ctx).Return(nil)          // tx.Commit() → ok

To test the rollback path, return an error from a repo call inside the transaction and assert the handler surfaces it — the mocked Tx lets you drive commit-vs-rollback at will (coverage checklist, case 6). No real transaction ever runs.

Level 2 — the driver (repository test)

A repository test can't mock "the repo" — the repo is the system under test. So you mock what the repo calls: pgx's Exec/Query/Scan. Doing that by hand is painful (pgx's Rows has many methods), so the house testutil.MockDB toolkit wraps it:

type MockDB struct {
    DB   *mock_database.Ext;   DB5 *mock_database.Ext5     // pgx v4 + v5 (a live migration)
    Rows *mock_database.Rows;  Rows5 *mock_database.Rows5
    Row  *mock_database.Row;   RawStmt *RawStmt            // the captured, parsed SQL
}

It gives you high-level helpers so a repo test reads at the level of "set up a query that returns these rows":

mockDB := testutil.NewMockDB()
mockDB.MockQueryArgs(t, nil, ctx, mock.Anything, database.TextArray(ids))   // program Query → Rows
mockDB.MockScanArray(nil, fields, [][]interface{}{ email1Vals, email2Vals })// fake TWO rows of Scan
// error cases: pass an err to MockQueryArgs, or pgx.ErrNoRows into the scan

The clever bit: faking Scan with reflection

How can a mock fill in a repo's scan targets without a database? MockScanArray programs the mocked Scan and uses .Run (Lesson 6's move 4) to copy the expected values into the caller's destination pointers via reflection:

m.Row.On("Scan", mockArgs...).Once().Run(func(args mock.Arguments) {
    for i := range args {
        reflect.ValueOf(args[i]).Elem().Set(reflect.ValueOf(values[i]).Elem())   // *dest = value
    }
}).Return(err)

When the repo calls rows.Scan(&e.ID, &e.Subject, …), this .Run fires and writes your prepared values straight into e.ID, e.Subject, etc. — exactly what a real Scan would do, minus the database.

Check yourself (from memory)

1. In-repo: mock/testutil/mock_db_wrapper.go:15-93, mock/testutil/sql.go, …/repositories/email_test.go:225-270, internal/golibs/database/db.go:24-36.