Write and run tests for features and fixes, starting with likely failures and boundary cases. Use behavior-focused checks, suitable test environments, and coverage results to assess whether changes are ready.
中文简介正在准备中。当前显示英语简介。
Testing workflow and quality standards for writing and running tests. Use when: (1) Writing new tests, (2) Adding a new feature that needs tests, (3) Modifying logic that has existing tests, (4) Before claiming a task is complete.
安装前可以查看交给 AI 代理的指令内容。
Standards and workflow for writing and running tests. Every feature must be tested.
Announce at start: "I'm using testing skill to ensure proper test coverage."
Vitest 4 — configured in vitest.config.ts.
tests/
├── unit/ # Individual functions, utilities, components
├── integration/ # IPC, database, service interactions
├── regression/ # Regression test cases
└── e2e/ # End-to-end tests (Playwright, playwright.config.ts)
| Environment | When | File naming |
|---|---|---|
node (default) | Main process, utilities, services | *.test.ts |
jsdom | DOM/browser-dependent code | *.dom.test.ts |
Before writing tests, list the riskiest scenarios first:
undefined / throws?Follow these quality rules:
1. Describe behavior, not code structure
// Wrong — describes implementation
it('should call repo.getConversation', ...)
// Correct — describes behavior
it('should return cached task without hitting repo on second call', ...)
it('should reject with error when conversation does not exist', ...)
2. Every describe block must cover at least one failure path
Happy-path-only tests leave the most dangerous code untested.
3. One behavior per test
Keep each it() focused. More than 3 expect() calls in one test is a signal it is testing too much at once.
4. Self-check
After writing a test, mentally delete the core logic it targets. If the test would still pass, rewrite it — it is not guarding anything.
5. Start from risk, not from coverage gaps
List scenarios most likely to produce bugs. Write those first. Coverage is the outcome, not the starting point.
bun run test # Run all tests (REQUIRED before every commit)
bun run test:coverage # Check coverage (before opening a PR)
Coverage target: ≥ 80% for all source files matched by vitest.config.ts → coverage.include (currently src/**/*.{ts,tsx} plus a few scripts).
New source files are automatically included in coverage — no manual config changes needed. If a new file is accidentally excluded by a rule in coverage.exclude, remove it from the exclude list.
When modifying logic, check if existing tests need updating:
bun run test -- --reporter=verbose # See which tests pass/fail with names
If a test fails because the behavior changed intentionally, update the test. If it fails unexpectedly, investigate.
When testing a module, verify:
null / undefined inputs handledBefore submitting code:
bun run test passescoverage.excludebun run test:coverage meets ≥ 80% target| Mistake | Correct |
|---|---|
| Testing implementation details | Test observable behavior |
| Only testing happy path | Must include at least one failure path |
5+ expects in one it() | Split into separate tests |
| Skipping tests for "simple" code | Simple code breaks too — test the risky parts |
| Writing tests after saying "done" | Tests are part of "done", not an afterthought |
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Organize an Electron app by placing new code in the right process and directory. Apply naming rules, component structure conventions, and process boundaries to guide additions and review existing code.
中文简介正在准备中。当前显示英语简介。
Prepare an AionUi release by checking AionCore assets, updating versions, and generating a changelog. Run quality checks, create a pull request with automatic merging enabled, then tag the merged release to trigger its build.
中文简介正在准备中。当前显示英语简介。
Manage multilingual interface text through translation keys. Follow the configured language list, reuse existing wording, update every locale, and regenerate and validate key types when adding text or translation modules.
中文简介正在准备中。当前显示英语简介。