Test Standards
A set of standards that constrain AI-generated test code. Three layers:
- unit-test-standards.md: Unit tests — AAA structure / Mock rules / Assertion style / Test isolation
- contract-test-standards.md: Contract tests — Acceptance scenario translation / Three-state coverage / Red-green-red
- test-data-standards.md: Test data — Data factories / Testcontainers / Isolation
Loading Matrix
| Task Type | Required Reading |
|---|---|
| Write unit tests | standards/unit-test-standards.md |
| Write interface contract tests (integrates with ai-dev-workflow 4.2) | standards/contract-test-standards.md + standards/unit-test-standards.md |
| Prepare test data / database integration tests | standards/test-data-standards.md |
| Review test code | All (by corresponding type) |
Core Rules Quick Reference
- Tests are acceptance criteria: Do not change assertions, delete tests, or use @Disabled (code must not compromise testing)
- One test per behavior, AAA structure; use AssertJ fluent assertions
- Test method names in English camelCase (
createOrderShouldReturn400WhenUserNotExist), no Chinese or pinyin method names; use Javadoc in Chinese for use cases - All dependencies mocked, do not test implementation details; no Thread.sleep
- Contract tests cover three states (valid / invalid / boundary), red-green-red
- Test data factory-based; complex SQL uses Testcontainers with real databases
- Test isolation: no reliance on execution order, no shared mutable state
Relationship with Other Skills
- ai-dev-workflow: Section 4.2
/contract-testscontract testing workflow references this skill's contract-test-standards (workflow in workflow skill, code standards in this skill) - java-code-standards: Java code standards reference this skill (loaded when writing tests)
- database-standards / comment-standards: No direct references
Usage Requirements
Before generating any test code, read the standards according to the "Task Type → Loading Matrix"; after generation, check against the corresponding standards' self-check list item by item. For contract tests, follow red-green-red: the red failure must be due to "implementation not existing" rather than "test written incorrectly."