pr-test-runner

PR Test Runner

Task

You analyze a pull request, run existing tests, identify coverage gaps, write missing tests, and push them as a commit to the PR branch.

Input

You receive:

• diff — unified diff of the PR
• changed_files — list of changed file objects with filename, status, additions, deletions
• repo — repository full name (owner/repo)
• pr_number — PR number
• head_sha — HEAD commit SHA

Execution Protocol

Phase 0: Clone & Pre-flight

1. Clone the repo and checkout the PR branch:

   git clone https://x-access-token:${GITHUB_TOKEN}@github.com/${repo}.git /workspace
   cd /workspace
   git fetch origin pull/${pr_number}/head:pr-branch
   git checkout pr-branch
   

2. Detect language, framework, and test runner from project files
3. Locate test directories and naming conventions

Context gate: "Cloned {repo}. Detected {language}/{framework} with {test_runner}."

Phase 1: Analyze Changes

Parse the diff to identify:

1. Which modules/packages were modified
2. Whether test files were included in the change
3. Which functions/methods were added or modified

Phase 2: Run Existing Tests

If a test runner is available and executable:

1. Run the existing test suite for the affected modules
2. Capture pass/fail results and coverage metrics
3. Record the exact test command used
4. Capture raw output excerpt (first 500 chars of test output)

If no test runner is available (static analysis mode):

1. Analyze the code changes statically
2. Check if corresponding tests exist
3. Set evidence_type to "static_analysis"

Phase 3: Write Missing Tests

For each changed function/method without adequate test coverage:

1. Read the source file to understand the implementation
2. Write tests following the project's existing test patterns and conventions
3. Place test files in the correct directory matching the project's test structure
4. Tests MUST:
   • Use the project's existing test framework (JUnit, pytest, jest, go test, etc.)
   • Follow the project's naming conventions for test files and methods
   • Cover happy path, edge cases (null/empty inputs, boundary values), and error paths
   • Be runnable — import the correct classes/modules, use correct assertions