# Mission — Unit testing in *this* repo

## Who this is for
A backend engineer in this monorepo who wants to write and read the codebase's **unit tests** with
fluency — Go `testing`, table-driven tests, **testify mocks**, and the repo's **mock generation** —
and to be **interview-ready** on Go testing technique.

Strong backend maturity (far from their first course). **Newer to this repo's test machinery**: the
`go-test-style` house rules, the `newSuite`/`assertExpected` pattern, testify `mock.Mock`, the two
bespoke mock generators (`gen-mock`), the `mock/` directory, and the `testutil.MockDB` toolkit that
fakes pgx without a database.

## The mission
> *"Based on the codebase and the web resources, teach me the unit testing here — Go test, mocks,
> generating mocks — so I can catch up on the repo and prepare for the interview."*

Two concrete targets:
1. **Catch-up fluency** — open any `*_test.go`, understand its structure, and write a new one that
   passes review: table-driven, mocked, covering the error paths, regenerated mocks and all.
2. **Interview readiness** — explain Go's testing model (table-driven + subtests), test doubles
   (mocks vs stubs), dependency injection for testability, and coverage — grounded in real code.

## The lead focus (chosen by the learner)
**Balanced test craft** — table-driven tests **+** testify mocks **+** the mock-generation tooling
**+** running tests, weighted evenly. No single facet dominates; the goal is the whole loop:
write → mock → generate → run → cover.

## The anchor (chosen by the learner)
**spike** (`internal/spike/modules/email/`) — the learner's own service, and the best-documented
one, with clean unit tests at every layer (repository, usecase/handler, gRPC controller). Every
lesson leans on spike's real tests; the `.claude/rules/go-test-style.md` conventions and the
`mock/`/`cmd/utils/mock` tooling are the supporting cast.

## Scope — unit tests ONLY
This course teaches the `go test ./internal/...`-driven, **testify-mock, `mock/`-backed** unit tests.
It deliberately **excludes** BDD/E2E: anything under `features/` or `internal/gandalf`, anything run
by `godog` / `local/run.bash bdd`, and repository tests that hit a real database. Those are a
separate world (the local Docker stack); we name the boundary and stop there.

## What "done" looks like
- Can write a table-driven test with `t.Parallel()` + `context.WithTimeout`, a `newSuite` factory,
  `// arrange / act / assert`, and `"return <result> when <condition>"` sub-test names.
- Can inject a **mock** (from `mock/`) into a struct's port field, program it with
  `.On(...).Return(...)`, match args with `mock.MatchedBy`, and verify with
  `mock.AssertExpectationsForObjects`.
- Can regenerate mocks (`make gen-mock-v2` / `make service=spike gen-mock-service`) and explain the
  **two generators** (reflection-based `GenMockStructs` vs the `mockery` wrapper).
- Can unit-test a **repository** with `testutil.MockDB` (no real DB) and a **usecase** with mock
  repos, covering the error-path checklist.
- Can run one test, the whole service, and read coverage (`make service=spike unit-test-service`,
  `-count=3`).

## Non-goals
- Not a Go-language course (that's `docs/golang/`). This is the **testing craft**, not the language.
- Not BDD/E2E/integration (out of scope by design — see above).
- Not exhaustive of every service's quirks (eureka-v2 sqlc mocks named, not taught) — spike
  generalizes.