auto-testability

name	auto-testability
description	Testability discipline for application code. Identifies when logic should be extracted into pure helpers, when routes/pages/components are carrying too much domain work, and when code needs seams for focused unit tests. Use when reviewing maintainability, refactoring for better tests, or validating whether code is easy to verify without brittle integration-heavy coverage.

Testability

Overview

This skill is about whether code can be tested cleanly, not whether tests exist.

A codebase can have many tests and still be hard to verify because the logic is trapped inside:

• route handlers
• page components
• giant service functions
• deeply stateful orchestrators
• inline conditional ladders repeated across call sites

The goal is to create code with clean seams:

• pure helpers for domain logic
• thin orchestration layers
• explicit dependencies
• narrow units that can be tested directly

When to Use

• Reviewing code structure after implementation
• Refactoring large pages, handlers, or services
• Evaluating whether a feature is easy to verify
• The user says "make this more testable", "extract this logic", or "why is this hard to test?"

Positive Patterns

Reward these:

• Pure helper extraction for pricing, validation, payload shaping, mapping, selection logic
• Rule/factory-driven validation instead of repeated if chains
• Thin routes/pages that orchestrate, while helpers/services own domain logic
• Focused unit tests around extracted pure logic
• Dependency boundaries around DB, network, file I/O, time, randomness
• Small workflow modules instead of giant transactional scripts

Negative Patterns

Flag these:

• Large handlers/components doing business logic inline
• $effect/UI blocks containing domain calculations that should be extracted
• Repeated validation logic across files
• Heavy conditional trees that should be data-driven or rule-driven
• Tests that must boot too much application surface just to validate one business rule
• Internal logic that can only be exercised through UI or API integration paths

What to Recommend

Extract pure helpers when:

• logic appears in 3+ places
• the logic has clear inputs and outputs
• the logic encodes business rules
• the tests currently need too much setup to reach it

Keep orchestration local when:

• it is mostly wiring state and calling helpers
• extraction would only move one trivial line
• the logic is tightly coupled to one UI/control flow boundary

Create seams for:

• time
• randomness
• external APIs
• persistence
• serialization/deserialization boundaries

Output Format

Testability Strengths

• What already has good seams

Testability Risks

• Where logic is trapped in high-friction locations

Recommended Extractions

• Exact helpers/modules to create or strengthen

Suggested Tests

• Which focused tests become possible after the extraction

Rules

• Do not equate “has tests” with “is testable”
• Prefer extraction of domain logic over adding more brittle integration tests
• Favor pure functions and narrow workflow modules
• Treat testability as an architectural quality, not a test-file concern