@doist/doistbot-cli 1.0.8 → 1.0.9

package/sandbox/src/tasks/review/prompts/review-focus-prompts/tests.md

@@ -2,27 +2,17 @@
 
 For this pass, focus only on test quality and test-design issues introduced by the diff.
 
-Flag findings when:
-
-- the new tests are disproportionately complex for the behavior being covered
-- the tests rely on unnecessary mocking or deep implementation knowledge
-- the change duplicates existing coverage instead of extending nearby tests
-- the highest-value, practically testable scenario introduced by the diff is still untested
-- the tests are brittle in a way that will create avoidable maintenance cost
-
-Only report a missing-test finding when all of the following are true:
-
-- you can name the specific behavior or regression path introduced by this PR
-- the behavior is important enough that a regression would create real user, data, integration, or maintenance risk
-- there is an existing, practical test path nearby: same module, adjacent tests, established fixture, or test harness already used for similar behavior
-- the requested test would be reasonably scoped and would not require setting up a new test framework, major harness, large fixture system, or unrelated infrastructure first
-
-Do not ask for tests solely because code changed. Avoid missing-test findings for CI scripts, one-off developer tooling, thin wrappers, mechanical config changes, or helper utilities unless the diff introduces meaningful branching, parsing, persistence, security-sensitive behavior, or another high-risk path with an existing practical test seam.
-
-If a change is worth testing but the module is not currently testable without significant setup work, do not file a blocking test finding. You may mention the testability gap only when it is the core design issue introduced by the diff.
-
-Do not ask for broad "more coverage" or tests for behavior that is already covered by adjacent tests.
-
-Do not report production-code issues here unless they are directly tied to a test-quality problem.
+Review the changes for potential testing issues, such as:
+
+1. High-signal suite: favor a smaller test suite over exhaustive coverage. Treat tests as carrying maintenance cost. Each test should protect important behavior, a realistic failure mode, or a stable shared contract.
+2. Low-value coverage: flag tests added only to cover implementation trivia. Examples include trivial getters/wrappers/constants, exact internal formatting, incidental telemetry/log details or events, timer internals, framework wiring with no behavior of its own, synthetic edge cases with no realistic breakage story, or behavior already covered by a higher-value test.
+3. Test bloat: redundant cases, copy-paste matrices, excessive or repeated setup that should use or extract a fixture/helper, gratuitous snapshots, or unparameterized variations that increase maintenance cost without clear regression signal. Suggest consolidation or deletion in these cases.
+4. Missing coverage: important behavior that can break without a test failing. Only ask for new tests when you can name the public/user-visible contract, security/privacy boundary, data-loss risk, serialization/wire contract, state transition, permission check, concurrency issue, or prior regression being protected.
+5. Weak assertions: tests that do not check observable behavior or invariants.
+6. Implementation-coupled tests: tests that assert private details, internal calls, or branch structure instead of behavior. Logs are worth testing only when logging itself is required behavior.
+7. Over-mocking: mocks that erase the behavior under test, hide integration behavior, or only prove mocks were called/configured. Prefer real fixtures or recorded external-service interactions when local practice supports them.
+8. Flaky patterns: time, random data, network calls, ordering, concurrency, or shared state that is not controlled by fixtures, clocks, cleanup, or deterministic assertions.
+
+Do not ask for tests just because code changed. Only flag a missing test when you can name the important behavior or failure mode that could break. Only flag test removal/simplification when the remaining suite still protects the important intended behavior.
 
 If the diff does not introduce any findings for this focus, return an empty comments array.