AgentSkillsCN

writing-tests

采用 Testing Trophy 模型,结合真实依赖项,编写以行为为核心的测试用例。适用于编写测试用例、选择测试类型,以及规避诸如“测试桩”之类的反模式。

SKILL.md
--- frontmatter
name: writing-tests
description: Writes behavior-focused tests using Testing Trophy model with real dependencies. Use when writing tests, choosing test types, or avoiding anti-patterns like testing mocks.

Writing Tests

Core principle: Test user-observable behavior with real dependencies. Tests should survive refactoring.

"The more your tests resemble the way your software is used, the more confidence they can give you." — Kent C. Dodds

Why this matters: Tests exist to give you confidence. The Testing Trophy prioritizes integration tests because they test real behavior across real modules — giving maximum confidence per test written. Unit tests in isolation often just test mocks, not your actual system.

Testing Trophy Model

PriorityTypeWhen
1stIntegrationDefault - multiple units with real dependencies
2ndE2EComplete user workflows
3rdUnitPure functions only (no dependencies)

Mocking Guidelines

Default: Don't mock. Use real dependencies.

Only mock:

  • External HTTP/API calls
  • Time/randomness
  • Third-party services (payments, email)

Never mock:

  • Internal modules
  • Database queries (use test DB)
  • Business logic
  • Your own code calling your own code

Before mocking, ask: "What side effects does this have? Does my test need those?" If unsure, run with real implementation first, then add minimal mocking only where needed.

Test Type Decision

code
Complete user workflow? → E2E test
Pure function (no side effects)? → Unit test
Everything else → Integration test

Assertion Strategy

ContextAssert OnAvoid
UIVisible text, rolesCSS classes, internal state
APIResponse body, statusInternal DB state
LibraryReturn valuesPrivate methods

Anti-Patterns

PatternFix
Testing mock callsTest actual outcome
Test-only methods in productionMove to test utilities
sleep(500)Use condition-based waiting
Asserting on internal stateAssert on observable output
Incomplete mocksMirror real API completely

Quality Checklist

  • Happy path covered
  • Error conditions handled
  • Real dependencies used (minimal mocking)
  • Tests survive refactoring
  • Test names describe behavior

Language-Specific Patterns

For flaky tests with timing issues, use Skill(ce:condition-based-waiting).


Remember: Behavior over implementation. Real over mocked. Outputs over internals.