Test File Preloading

Before the agent loop starts, GitAuto scans the repository for existing test files and pre-loads existing test files into the model's context. These serve as concrete examples of the project's testing patterns, import conventions, and assertion styles.

Why This Exists

Without existing test files in context, generated tests are inconsistent with the rest of the codebase: wrong import paths, different test framework usage, unfamiliar assertion styles, and missed helper utilities. Every generated test feels like it was written by someone who had never seen the codebase. Pre-loading real test files from the repo teaches the model by example. If your tests use a custom render helper, the model sees it. If your tests follow a specific describe/it nesting pattern, the model replicates it. If your tests import from @testing-library/react with specific utilities, the model picks up that convention automatically.

Why Models Prefer Creating Over Finding

Models have a strong bias toward generating new content rather than searching for existing content. Searching requires multiple tool calls with uncertain outcomes - the model has to guess file paths, run searches, interpret results, and try again if nothing comes back. Creating a new file is a single confident action with a guaranteed result. Left unchecked, the model will attempt a few searches, find nothing (or give up early), and create a brand new test file - ignoring the existing test suite's patterns, helpers, and conventions entirely. This is why GitAuto performs the search outside the model and injects the results before the model starts.

How It Works

GitAuto discovers test files through two methods: path matching (walking the file tree for test files whose path contains the implementation file's stem) and content grep (finding test files that reference the stem in their source code). This hybrid approach catches both colocated tests and tests in separate directories that import the implementation file.

Discovered test files are then ranked by relevance using a scoring system: name match (+100 if the test file name contains the implementation stem), same directory (+50), shared path components (+10 per shared component), and a distance penalty. The top 5 most relevant test files are included with their full contents. Any remaining test files are listed as paths so the model knows they exist without consuming context budget.

This is critical because the model will happily give up searching after a few attempts and create a new file instead. By doing the search and ranking upfront outside the model, GitAuto guarantees that the most relevant existing tests are found and their content is injected into the initial context before the model begins its work.

Related Features

• Test Naming Detection - detects the dominant naming convention across all test files
• Coding Standards - codified rules that complement the examples from preloaded files