Copilot path-specific instructions for tests
A free .github/instructions/tests.instructions.md for GitHub Copilot that applies only to test files: run commands, behavior-first tests, accessible queries, mocking at the boundary and no weakened assertions.
- Install
.github/instructions/tests.instructions.md- Last tested
- GitHub Copilot · 2026-10-29
Besides the repo-wide .github/copilot-instructions.md, GitHub Copilot reads path-specific instructions from NAME.instructions.md files in .github/instructions/. Each one starts with an applyTo frontmatter glob, and you can list several patterns separated by commas. When a file Copilot is working on matches, it uses both the path-specific file and the repo-wide one.
This file targets test files only (*.test.*, *.spec.*, tests/ and __tests__/ folders), so its testing rules don't crowd every other request. Edit applyTo to match your layout, and fill in the [bracketed] runner and commands. Per GitHub's docs, checked on October 29, 2026, path-specific instructions on GitHub.com are used by Copilot cloud agent and Copilot code review. Add excludeAgent: "code-review" or "cloud-agent" to the frontmatter if you want only one of them to read it.
Code review reads instructions from the pull request's head branch, so you can test changes to this file in the same PR that adds it. Start with our free copilot-instructions.md for Next.js for the repo-wide file.
tests.instructions.md---
applyTo: "**/*.test.ts,**/*.test.tsx,**/*.spec.ts,**/*.spec.tsx,**/tests/**,**/__tests__/**"
---
# Instructions for test files
These instructions apply when Copilot works on test files in this repo. Repository-wide rules in `.github/copilot-instructions.md` still apply.
## Framework and commands
- Test runner: [Vitest | Jest | Playwright for e2e]. Use the runner's own APIs; don't mix Jest and Vitest globals.
- Run one file: `[pnpm vitest run path/to/file.test.ts]`. Run the suite: `[pnpm test]`.
- Never say tests pass unless you ran them. Report the command and the result.
## What a good test here looks like
- Test behavior through the public interface (exported functions, rendered UI, HTTP responses), not private helpers or implementation details.
- One behavior per test. Name tests as a sentence describing it: `it("returns 404 when the post does not exist")`.
- Arrange, act, assert, in that order, with the assertion close to the action.
- Cover the happy path plus the important failure: invalid input, missing auth, not found, empty list.
- For UI, query by role and accessible name (`getByRole("button", { name: "Save" })`), not by CSS class or test id unless there is no accessible alternative.
## Data, mocks and isolation
- Build test data with the factories in `[tests/factories]`; don't copy large JSON fixtures into tests.
- Mock at the boundary (network, clock, randomness, third-party SDKs), not the module under test. Reset mocks between tests.
- Use fake timers instead of real waits. No `sleep`, no arbitrary timeouts.
- Tests must not depend on order, on each other, on the real network or on real credentials.
## Never
- Delete, skip or weaken an existing assertion to make a change pass. If a test is wrong, say why and fix the expectation.
- Leave `.only`, `.skip` or `console.log` in a committed test.
- Update snapshots without explaining what changed and why it's expected.
