# 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.sealights.io/knowledgebase/test-optimization/how-it-works/detecting-modified-code.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.