test-engineer
When designing test strategy, analysing coverage, or writing tests outside the TDD cycle. Also use when working with CI pipelines or validating changes end-to-end.
- License 许可
- MIT
- 最近更新
- 2026-11-07
- Stars
- ★ 13
- Forks
- 3
01 前言 Front Matter
- name
- test-engineer
- license
- MIT
- description
- When designing test strategy, analysing coverage, or writing tests outside the TDD cycle. Also use when working with CI pipelines or validating changes end-to-end.
03 SKILL.md 正文
Test Engineer Standards
Testing Rules
- All new logic must include unit and integration tests.
- Simulated or test data must be clearly marked and never promoted to production.
- All tests must pass in CI pipelines before deployment.
- Code coverage should exceed 85% on business logic modules.
- Regression tests must be defined for all high-impact updates.
- Log test outcomes in separate test logs, not production logs.
Test Structure
<!-- PLATFORM: Android -->
Android
- Prefer unit tests over instrumented tests when business logic is isolated.
- Use MockK for mocking. Use Espresso for UI testing.
- Name test functions with backticks:
@Test funwhen input is X, expect Y() {} - Use Given/When/Then (Arrange-Act-Assert) structure. <!-- END PLATFORM: Android -->
<!-- PLATFORM: iOS -->
iOS
- Use XCTest for unit and integration tests. Use XCUITest for UI testing.
- Use protocol-based fakes over mocking frameworks where possible.
- Name tests descriptively:
test_scenario_expectedOutcome. - Use Given/When/Then (Arrange-Act-Assert) structure. <!-- END PLATFORM: iOS -->
<!-- PLATFORM: Web -->
Web
- Use Jest or Vitest for unit tests. Use Playwright or Cypress for E2E.
- Name tests descriptively:
it('should do X when Y'). - Mock external dependencies; prefer dependency injection over module mocks.
- Use Given/When/Then (Arrange-Act-Assert) structure. <!-- END PLATFORM: Web -->
<!-- PLATFORM: Backend -->
Backend
- Use the language's standard test framework.
- Name tests descriptively — the name should explain the scenario and expected outcome.
- Use the project's standard mocking library for test doubles.
- Use Given/When/Then (Arrange-Act-Assert) structure. <!-- END PLATFORM: Backend -->
Verification
- Diff behavior between main and your changes when relevant.
- Ask yourself: "Would a staff engineer approve this?"
- Run tests, check logs, demonstrate correctness.
Error Handling Design
- Error handling logic must be designed using test-first principles.
- Retry logic must include exponential backoff and failure limits.
04 同仓库更多 Skills
setup-project
When setting up agentskel on a new project that does not yet have .memory/ or .agents/. Use when the user says "set up agentskel", "install agentskel", or "add agent memory to this project".
using-git-worktrees
When running long feature implementations, parallel branch work, or build/test scripts that must not interfere with the user's active working directory. Creates isolated execution environments via git worktrees in sibling directories.
test-driven-development
When implementing logic changes during develop-feature or implement-task. Use the Red-Green-Refactor cycle to write a failing test before any production code.
task-planner
When decomposing a feature or spec into implementable subtasks, estimating scope, or orchestrating multi-step work across subagents.
systematic-debugger
When applying debugging techniques during any investigation — root cause tracing, bisect, defense-in-depth. Enforces hypothesis-first analysis and prohibits guess-and-check changes. Use standalone or inside the debug-issue workflow.
domain-expert
When working on features that require domain knowledge — business rules, terminology, or invariants specific to this project. [Replace this description and the content below with your project's domain.]