Add tests to a package

​

Before you start

• Your repo has a .bellows.yaml with an image and a test gate. See Configure your repo.
• You know how gates run, including on_demand and filter.
• If the integration tests need Postgres or Redis, declare it as a service.
• You can create tasks in the app, the CLI or the MCP server. See Run tasks.

​

Steps

environment:
    image: golang:1.25
    cache:
        - GOCACHE
        - GOMODCACHE
    setup: "go mod download"
    gates:
        - name: build
          command: "go build ./..."
          timeout: 5
        - name: test
          command: "go test -race -count=1 ./..."
          timeout: 10
        - name: test-filter
          command: 'go test -race -count=1 -run "$GATE_FILTER" ./...'
          on_demand: true
          filter: true

        - name: coverage
          command: 'go test -count=1 -coverprofile=c.out ./internal/notes/ && go tool cover -func=c.out | awk "/^total:/ { sub(/%/, \"\", \$3); exit (\$3 < 80) }"'
          timeout: 10

Add unit tests for the notes package in internal/notes.

Cover these cases:
- Create: empty title is rejected, title over 200 chars is rejected,
  duplicate title for the same user is rejected.
- Update: unknown id returns ErrNotFound, a stale version returns ErrConflict.
- Delete: deleting twice is idempotent.
- List: pagination returns the right page and an empty page past the end.

Use table-driven tests and the existing fakes in internal/notes/testutil.
Do not change production code. If you find a bug, leave a failing test
out and describe the bug in the pull request instead.

Run the test-filter gate while you iterate, then run the full test gate
before you finish.

​

What you get

• A pull request that adds only test files, when you said not to touch production code.
• Gate results in the task’s Verification panel: build, test and, if you added it, coverage.
• A summary of what was covered and what was skipped, in the pull request and the final message.

​

Tips

• One package or endpoint per task. A narrow task finishes faster and gives a pull request you can read.
• Say “do not change production code” when that is what you want. Otherwise the agent may refactor to make code testable.
• Name the cases. “Add tests” gets happy paths. A list of edge cases gets edge cases.
• Read the test names in the diff first. They show quickly whether the agent understood the cases.
• Follow up for gaps, for example “add a test for a nil context in Create”. The agent continues in the same checkout. See Task lifecycle.
• Keep the filtered gate at 10 minutes or less, or the agent cannot run it while it works.

​

Variations

• Postgres-backed tests. Add a db service and point your test at localhost. See Services.
• Node project. Use npx vitest run $GATE_FILTER for the filtered gate and npm_config_cache in cache.