docs: cover new work with end-to-end tests

State the testing strategy in CLAUDE.md — a change is exercised by running
sqlc the way a user does, against a schema, a query file and a committed
golden, rather than by a unit test on an internal function — and describe
how an endtoend case is laid out.

Drop the seed package's unit test accordingly. The dialect descriptions it
covered are exercised by the analyze cases under internal/endtoend/testdata,
which run every dialect through the catalog it seeds.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011MnoUabwBWW9gaEn2Nj7eG

Author: claude

CLAUDE.md

@@ -89,18 +89,23 @@ go test -v ./internal/config -run TestConfig
 go test -race ./internal/config
 ```
 
-## Test Types
+## Testing Strategy
 
-### 1. Unit Tests
+**Cover new work with end-to-end tests, not unit tests.** A change to the
+compiler, an engine, the analysis core or codegen is exercised by running sqlc
+the way a user does — a schema, a query file and a committed golden output —
+so the test says what sqlc produces rather than what an internal function
+returns. Internal APIs move around; the SQL that goes in and the output that
+comes out is the contract worth pinning down.
 
-- **Location:** Throughout the codebase as `*_test.go` files
-- **Run without:** Database or external dependencies
-- **Examples:**
-  - `/internal/config/config_test.go` - Configuration parsing
-  - `/internal/compiler/selector_test.go` - Compiler logic
-  - `/internal/metadata/metadata_test.go` - Query metadata parsing
+Adding coverage means adding a directory under `/internal/endtoend/testdata/`,
+not a `*_test.go` next to the code. Reach for a unit test only when the
+behavior genuinely cannot be reached through the CLI, and say why in the test.
 
-### 2. End-to-End Tests
+Some `*_test.go` files predate this and remain; they are not a precedent for
+new ones.
+
+### End-to-End Tests
 
 - **Location:** `/internal/endtoend/`
 - **Requirements:** `--tags=examples` flag and running databases
@@ -111,7 +116,15 @@ go test -race ./internal/config
   - `TestJsonSchema` - JSON schema validation
   - `TestExamplesVet` - Static analysis tests
 
-### 3. Example Tests
+A case is a directory holding the inputs and the expected output. `exec.json`
+names the command and its arguments — omit it and the case runs `generate`,
+comparing the generated files against the ones committed alongside; give it
+`{"command": "analyze", "args": [...]}` and the case compares the command's
+stdout against `stdout.txt`. A case that is expected to fail commits its
+`stderr.txt`. Regenerate a golden by running the command in its directory and
+writing the output back over the committed file.
+
+### Example Tests
 
 - **Location:** `/examples/` directory
 - **Requirements:** Tagged with "examples", requires live databases
@@ -232,9 +245,10 @@ go run ./cmd/sqlc-test-setup start
 ## Tips for Contributors
 
 1. **Run tests before committing:** `go test --tags=examples -timeout 20m ./...`
-2. **Check for race conditions:** Use `-race` flag when testing concurrent code
-3. **Use specific package tests:** Faster iteration during development
-4. **Read existing tests:** Good examples in `/internal/engine/postgresql/*_test.go`
+2. **Cover new behavior end to end:** Add a case under `/internal/endtoend/testdata/`
+3. **Check for race conditions:** Use `-race` flag when testing concurrent code
+4. **Iterate on one case:** `go test ./internal/endtoend -run 'TestReplay/base/<case>'`
+5. **Read existing cases:** `/internal/endtoend/testdata/` has one per feature
 
 ## Git Workflow