# Detecting Modified Code

Test Optimization generates test recommendations for each test runner at every test stage by first identifying all code changes that require testing. SeaLights employs a Build Scanner agent to scan all binaries and artifacts during each build, mapping the code and detecting changes at the method/function level.

### Basic Comparison Logic

For standard **App-Level** stages, Test Optimization compares the new build with the code used in the last execution of that specific test stage. However, for complex environments involving multiple services, a more robust comparison logic is applied.

### Detailed Implementation: Cross-App Recommendation Logic

In a **Cross-App Test Stage**, recommendations are calculated by comparing the current state of the environment against the versions present during the previous successful test execution.

#### Comparison Points

The engine analyzes the version differences between:

1. **Current Test Cycle:** The applications and versions available in the environment when the recommendations were requested.
2. **Previous Test Cycle:** The applications and versions that were part of the previous recommendation calculations consumed in that Test Stage.

#### Exclusions and Stable Comparison Rules

To ensure performance and stability in dynamic environments, certain differences are intentionally ignored:

<table><thead><tr><th width="240.2265625">Exclusion Type</th><th>Description</th></tr></thead><tbody><tr><td><strong>Missing Applications</strong></td><td>Applications present in the Previous Test Cycle but missing from the Current Cycle are ignored.</td></tr><tr><td><strong>Late-Loading Applications</strong></td><td>Applications that appear after the recommendation generation process has started are ignored.</td></tr><tr><td><strong>Branch Differences</strong></td><td>The engine ignores branch names and instead compares the <strong>hash</strong> of the method/function. This ensures the comparison is based purely on code content.</td></tr></tbody></table>

#### Handling Multiple Builds for a Single Application

If an application is reported with multiple builds within a single Test Cycle, specific logic is applied to determine which build version is used for comparison. This is a conservative approach designed to maximize coverage and prevent the unintended omission of necessary tests.

| Scenario                           | Comparison Logic         | Rationale                                                                                       |
| ---------------------------------- | ------------------------ | ----------------------------------------------------------------------------------------------- |
| **Current Test Cycle**             | Use the **newer** build. | Ensures the most up-to-date code version is used to determine changes.                          |
| **Previous Test Cycle (Baseline)** | Use the **older** build. | Establishes a safe, "wider" baseline to ensure no changes introduced between builds are missed. |

***

Once these code changes are identified, Test Optimization selects the specific tests impacted by these modifications for execution.