waypoint-codex 1.0.11 → 1.0.12
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: test-writing
|
|
3
|
+
description: Write a small, high-signal test set that protects important behavior without overfitting to implementation details. Use whenever adding or modifying automated tests for a feature, bug fix, refactor, or behavior change. Prefer durable tests that verify user-visible behavior, important business rules, and meaningful failure modes. Avoid redundant, brittle, or low-value tests that increase maintenance cost without materially increasing confidence.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Write tests for confidence, not volume.
|
|
7
|
+
|
|
8
|
+
Start with the smallest test set that gives strong confidence in the requested change.
|
|
9
|
+
|
|
10
|
+
Default test budget for a normal feature or bug fix:
|
|
11
|
+
- one main-path test
|
|
12
|
+
- one key edge case or failure-path test
|
|
13
|
+
- unit tests only for non-trivial pure logic
|
|
14
|
+
|
|
15
|
+
Test at the highest level that gives strong confidence at reasonable cost.
|
|
16
|
+
|
|
17
|
+
Prefer tests that:
|
|
18
|
+
- verify observable behavior
|
|
19
|
+
- protect important business rules and invariants
|
|
20
|
+
- cover meaningful boundaries and failure modes
|
|
21
|
+
- survive refactors
|
|
22
|
+
- exercise public interfaces rather than private helpers
|
|
23
|
+
|
|
24
|
+
Avoid tests that:
|
|
25
|
+
- duplicate confidence across layers without a distinct risk
|
|
26
|
+
- assert implementation choreography instead of outcomes
|
|
27
|
+
- test trivial helpers, thin wrappers, pass-through glue, or obvious mappings
|
|
28
|
+
- encode fragile structure such as incidental DOM shape, exact class strings, private function calls, or unstable snapshots
|
|
29
|
+
- expand a feature into a large matrix of low-value cases unless the risk truly requires it
|
|
30
|
+
|
|
31
|
+
When choosing between many narrow tests and one stronger test, prefer the smaller set that better protects real behavior.
|
|
32
|
+
|
|
33
|
+
For frontend work:
|
|
34
|
+
- prefer stable user-visible behavior over structural assertions
|
|
35
|
+
- add automated regression tests only when the behavior is worth protecting and likely to remain stable
|
|
36
|
+
- do not add large numbers of UI tests for cosmetic or refactor-sensitive details
|
|
37
|
+
|
|
38
|
+
For backend or domain logic:
|
|
39
|
+
- prefer behavior-focused tests around contracts, invariants, validation, permissions, state transitions, and real regressions
|
|
40
|
+
- add targeted unit tests for tricky pure logic only when they materially improve confidence
|
|
41
|
+
|
|
42
|
+
If an integration-style test already proves the important flow, do not add multiple lower-level tests that mostly restate the same confidence.
|
|
43
|
+
|
|
44
|
+
Before finishing, remove or avoid any test whose main effect is to make future refactors harder without protecting an important contract.
|
|
45
|
+
|
|
46
|
+
Rules:
|
|
47
|
+
- Do not optimize for test count.
|
|
48
|
+
- Do not mirror the implementation structure in the test structure.
|
|
49
|
+
- Do not create one test per helper by default.
|
|
50
|
+
- Do not add redundant tests across layers unless a distinct risk justifies them.
|
|
51
|
+
- Do not test trivial code just because it exists.
|
|
52
|
+
- Prefer the smallest durable set that gives high confidence.
|