test-repository

Write Go persistence-layer tests against real PostgreSQL using dockertest and BDD tables.

Updated Sep 14, 2026
One-click install
npx skills add https://github.com/nakamori-naoya/go-convention-plugins --skill test-repository-nakamori-naoya
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: test-repository
Source: https://github.com/nakamori-naoya/go-convention-plugins/tree/main/plugins/go-convention/skills/test-repository
Command: npx skills add https://github.com/nakamori-naoya/go-convention-plugins --skill test-repository-nakamori-naoya

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Writing repository and query service tests in Go often drifts into mocks, partial assertions, or ad-hoc fixtures that fail to verify what actually changed in the database. This Skill enforces a convention where every BDD scenario from the data-model document is replayed on a real PostgreSQL instance, with all tables compared row-by-row before and after each operation. ## Core Features & Use Cases - Full-table BDD verification: Repository tests drive restore → real aggregate operation → save, then assert every table's rows match the document's After state, including DB constraint translation, optimistic-lock conflicts, concurrency, and NotFound cases. - Query service testing: Seed Before rows, call the read method, and compare returned DTOs across filter, paging, NULL, and empty-result perspectives. - Deterministic infrastructure: A single dockertest-based rdbtest.Start in TestMain, typed Seed{Table}/Read{Table} helpers generated via sqlc, and a check-bdd-coverage.py script that verifies every BDD ID appears either as a test case or a documented omission. - Use Case: Given a data-model document with BDD-001 through BDD-010 for a room reservation aggregate, generate TestReservationRepository_ApplyHeld and sibling tests that seed rows, run concurrent transactions, and assert all eight tables match the documented After state. ## Quick Start Ask the AI to write repository tests from this data-model document's BDD scenarios, verifying all tables on a real PostgreSQL database.

Frequently Asked Questions about test-repository

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test a Go repository against a real PostgreSQL database?▼

Use dockertest to start one PostgreSQL container in TestMain, share the pgxpool connection across tests, and reset all tables per case. Drive each test with restore, real aggregate operation, then save, and assert every table's rows afterward.

How to write table-driven repository tests from BDD scenarios?▼

Map each BDD ID to a test case with seed{Table} fields for the Before rows and want{Table} fields for the After rows across all tables. The loop body runs Reset, all Seeds, the operation inside a transaction, then Read and assert.Equal for every table.

Does dockertest work with Go TestMain for integration tests?▼

Yes, dockertest v4 starts PostgreSQL in TestMain via a single Start helper that waits with Retry until Ping succeeds and applies the schema. Startup failure must fail the test run with log.Fatalf rather than t.Skip.

How do I test concurrent transactions and optimistic locking in Go?▼

Make the When field a slice and run each element in a goroutine with sync.WaitGroup.Go inside real transactions. Fix the first entry to commit first using a rendezvous channel, then assert the last entry receives the conflict or constraint sentinel.

When should repository tests not cover a BDD scenario?▼

Skip scenarios the aggregate itself rejects, such as eligibility, deadline, or ownership rules, since those never reach the repository. List each omitted BDD ID with its reason in a trailing comment block at the end of the test file.