Our Approach

  1. Analysis

Our tool begins with a detailed change impact analysis. This includes:

  • Precisely identifying what has changed (including indirect dependencies)

  • Static code analysis to map how the project interacts with the dependency changes

  • Static analysis of existing unit tests as a starting point for validation

Call‑graph impact analysis diagram showing Go project functions (dark blue circles) on the left linked by lines to module functions on the right, illustrating direct and transitive dependency changes.

2. Expand

After understanding dependency changes and project interactions, we expand testing coverage to validate stability:

  • Identifying valuable points to monitor field values across the project. Allowing us to witness behavior changes anywhere in the project, not just at the unit test validations.

  • AI-powered expansion of unit tests to expand change behavior coverage.

The advantage to our field level inspection is that the test expansions don’t need to concern themselves with assertions. Instead we just complete the coverage and use the field analysis to determine if there is a behavior change.

By having such a detailed analysis done prior, we can ensure that our field state checks, and later the validation step targets only areas of the project and module that are relevant for the change. This keeps our tool fast. Our techniques are very detailed, and must be targeted in order to have reasonable execution times.

Side‑by‑side flowchart: standard unit test sequence vs. PatchLens AI‑driven test expansion with added verification checks.

Once prepared, our tool is aware of the intersection from the dependency change and the project. We must then validate:

  1. Are there obvious test failures to consider, if so we try to detect where the behavior change started.

  2. At points where the project intersects a call path to a changed module function, are there any internal field or behavior changes.

  3. The confidence that the tool was able to validate that behavior change.

We determine the risk by performing a combination of unit testing and the field analysis described in the expand section above.

The confidence is determined by validating that the above testing reached the targeted points of change in the module, followed by introducing bugs in the module and confirming the ability for the modified test suite to be able to detect the fake defects.

3. Validate

Static call‑graph showing field state analysis and module change impact, with risk and confidence bars.