File Type Detection
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
File Type Detection is a foundational mechanism within the TDD Guard system used to categorize files into "Test files" or "Implementation files." This categorization is critical because the system applies fundamentally different Test-Driven Development (TDD) validation rules based on the detected type. By analyzing file paths during tool operations (such as Write, Edit, or MultiEdit), TDD Guard determines which phase of the Red-Green-Refactor cycle an agent is currently in.
The detection logic ensures that "Red" phase activities—such as adding a new failing test—are permitted in test files without prior output, while "Green" phase activities in implementation files are strictly gated by existing test failures.
Sources: src/validation/prompts/file-types.ts:1-7, src/validation/prompts/rules.ts:4-15
Detection Logic and Categories
The system uses pattern matching on the file path to distinguish between file categories.
Classification Rules
| Category | Path Pattern Matching | Description |
|---|---|---|
| Test Files | Contains .test., .spec., or test/ | Files intended for test definitions and infrastructure. |
| Implementation Files | All other source files | Files containing the actual logic of the application. |
Sources: src/validation/prompts/file-types.ts:4-7, src/validation/prompts/operations/write.ts:7-9
Technical Workflow
When a tool operation is intercepted, the system follows a specific sequence to apply type-based rules:
The detection must be the "FIRST" step performed during the review of any Write, Edit, or MultiEdit operation to ensure the correct logic is applied.
Sources: src/validation/prompts/operations/write.ts:7-9, src/validation/prompts/operations/edit.ts:8-10, src/validation/prompts/operations/multi-edit.ts:8-10
Type-Specific Validation Rules
Test File Constraints
Detection of a test file triggers rules focused on incremental test development.
- Allowed: Adding exactly one new test is always permitted, as this represents the start of the TDD cycle.
- Allowed: Modifying existing tests or setting up test utilities/infrastructure.
- Violation: Adding multiple new tests simultaneously (e.g., adding two
test()blocks in one operation). - Refactoring: Only allowed if "relevant tests" (those within the file) are passing.
Sources: src/validation/prompts/file-types.ts:10-25, src/validation/prompts/operations/edit.ts:14-25
Implementation File Constraints
Detection of an implementation file triggers strict dependency on test results. The system maps specific test failure types to allowed implementation changes:
| Detected Failure Type | Allowed Implementation Logic |
|---|---|
| "X is not defined" | Create empty class or function stub only |
| "X is not a constructor" | Create empty class only |
| "X is not a function" | Add method stub only |
| Assertion Error (Expected X to be Y) | Implement minimal logic to pass assertion |
| No Test Output | No implementation allowed |
Sources: src/validation/prompts/file-types.ts:31-40, src/validation/prompts/operations/edit.ts:31-38
Integration with Tool Operations
The detection logic is embedded in the prompt generation for various tool operations, ensuring the AI validator receives the correct context for the specific file type.
The generateDynamicContext function assembles these rules into a cohesive prompt. It ensures that if a Write operation is detected on a test file, the validator is specifically instructed to check for the number of tests in the new content.
Sources: src/validation/context/context.test.ts:35-50, src/validation/prompts/operations/write.ts:11-18, src/validation/prompts/operations/multi-edit.ts:12-20
Summary
File Type Detection is the primary gatekeeper for TDD Guard's validation logic. By accurately identifying files as either test-related or implementation-related based on path strings like .test. or test/, the system can enforce the Red-Green-Refactor cycle effectively. This ensures that developers cannot add implementation logic without a detected failing test, and cannot add multiple tests at once, preserving the incremental nature of Test-Driven Development.