Build 3 — Add Tests to Untyped Code

# Build 3 — Add Tests to Untyped Code ## The brief Take an existing untyped Python codebase (your own or one provided) and use AI to add tests + types in tandem. Both improve the codebase; AI accelerates both. ## Why both at once Adding types reveals what tests should cover (type signatures define contracts). Adding tests reveals what types ARE (the actual behavior). They reinforce each other. ## Starting point A codebase with: - Functions without type hints. - Few or no tests. - Behavior knowable only by reading code. Could be 300-2000 lines. Pick something small (200-500 lines) for this build. ## Step 1: Audit (10 min) ```bash pyright src/ # how many type errors? coverage report # what's covered? ``` Note the baseline. Pyright will give hundreds of errors; coverage will be low. ## Step 2: Plan (10 min) Discuss with AI: > "I have this untyped codebase [paste/share files]. I want to add type hints AND tests. What order should I work in? Start with public APIs or internal functions?" AI suggests starting with public APIs (most-used; types matter most). Then tests for each. Order: 1. Top-level functions (public API). 2. Add types + minimal docstrings. 3. Add tests for each. 4. Move to internal functions. 5. Iterate. ## Step 3: Type the public API (15 min) Pick one public function. Look at it; understand what it does. > "Add type hints to this function. Don't change behavior. If types are unclear from code, ask me." AI adds: ```python def fetch_user(user_id: int) -> dict[str, Any] | None: ... ``` If you don't know what it returns, AI asks. You answer. AI updates types. ## Step 4: Test the function (15 min) > "Generate pytest tests for fetch_user. Based on the type signature and the implementation, test happy path, missing user (returns None), and any other behavior you observe." AI generates tests. Run them; they pass against current code. Now you have: - A typed signature (contract). - Tests verifying behavior. - Documentation (implicit in types + tests). ## Step 5: Repeat for each public function Same pattern. Type. Test. Verify. ## Step 6: Identify the gaps After typing public APIs, you'll notice: - Internal functions still untyped. - Some return types are `Any` (didn't know better). - Edge cases not tested. Iterate: - Refine `Any` to specific types. - Add tests for edge cases AI mentioned. - Add types to internal functions. ## Step 7: Type-check + test ```bash pyright src/ # errors should drop pytest --cov # coverage should climb ``` Target after this build: pyright basic mode passes; coverage > 70%. For strict mode + 90% coverage: takes more iteration. ## Step 8: Document findings ```markdown # Retrofit Reflection ## Codebase stats Before: - Type errors (pyright basic): 247 - Test coverage: 12% After: - Type errors: 0 - Test coverage: 73% ## What AI helped with most - Generating tests from function signatures. - Inferring types from usage patterns. ## What I had to do manually - Confirming ambiguous return types. - Edge cases AI didn't think of. ## Surprises - Found 2 actual bugs while adding types (functions returned wrong types). - Found 3 untested branches. ``` ## Deliverables - Codebase with type hints on public APIs. - Tests covering happy path + key edge cases. - Pyright passes basic mode. - Coverage > 70%. - Reflection document. ## What you'll learn - Types reveal contracts; tests verify them; they reinforce. - AI accelerates both — read the function; types + tests follow. - Untyped code often has hidden bugs that types reveal. - AI-suggested tests miss edges — add them yourself. - Incremental approach works (don't try perfect; aim for better). ## Stretch - Pyright strict mode passes. - Coverage > 90% on critical modules. - Add tests for any bugs found during the retrofit.