Pre-Implementation Test Coverage Verification

Procedures

Step 1: Resolve Test Paths

1. Collect the list of existing source file paths that will be modified. Accept only .cs files that already exist in the repository — skip files to be created.
2. Execute the path resolver to filter testable classes and map expected test paths:

   python3 scripts/resolve-test-path.py --batch <file1.cs> <file2.cs> ...

3. Parse the JSON output. Each entry contains:
   • testable: whether the file warrants a test check.
   • test_path: the expected test file location.
   • glob_pattern: a fallback glob pattern for discovery.
   • skip_reason: why a file was excluded (if not testable).
4. If the classification rules need review, read references/layer-mapping.md for the full include/exclude criteria.

Step 2: Verify Test Existence

1. For each entry where testable is true: a. Check if the file at test_path exists. b. If not found, run a Glob search using the glob_pattern value inside the corresponding test project directory. c. Classify the file as covered (test found) or uncovered (no test found).
2. Collect all uncovered files into a report list.

Step 3: Report Findings

1. Read assets/output-template.md to format the output consistently.
2. If all files are covered, display the "All Covered" message and return — no user interaction needed.
3. If uncovered files exist, display the "Missing Tests" prompt listing each uncovered file with its expected test path, then ask the user whether to create the tests before implementation.

Step 4: Handle User Decision

If the user confirms (y/yes/s/sim):

1. For each uncovered file: a. Read the source file in full to identify the SUT (System Under Test), its constructor dependencies, and public methods. b. Invoke the criar-testes-unitarios skill providing the source code and dependencies. c. Save the generated test file at the test_path resolved in Step 1.
2. After all test files are generated, validate the batch: a. Build: Execute dotnet build <TestProject> for each affected test project. b. Run: Execute dotnet test <TestProject> --filter "FullyQualifiedName~<TestClassName>" for each generated test class.
3. If build or test failures occur, correct and retry (maximum 2 attempts per file).
4. If a file still fails after 2 attempts, display the "Partial Failure" prompt from assets/output-template.md and ask whether to proceed without that file's tests.
5. Display the "Tests Created Successfully" message with the count of files covered.

If the user declines (n/no/nao):

1. Display the "User Declined" message and return immediately.

Error Handling

• Script failure: If scripts/resolve-test-path.py returns non-zero, inspect stderr for the specific error. Verify the input paths are relative and use forward slashes.
• Test project missing: If the target test project directory does not exist (e.g., no SistemaAcademia.Repositorio.Test/), inform the user and ask whether to proceed without tests for that layer.
• Build failure after generation: Read the compiler output, identify the missing using or type mismatch, correct the generated test file, and rebuild. Maximum 2 retries.
• Test execution failure: Read the test output, identify assertion or setup issues, correct the test, and re-run. Maximum 2 retries.
• Complex source file: If the source class has more than 10 constructor dependencies, generate tests only for the top 3-5 public methods by complexity. Report which methods were covered and which were skipped.