Unit Tests Can Accidentally Use Developer IDEasy Installation

[maybeec]

Actual behavior

During unit test execution, the AbstractIdeContext constructor (lines 183-203) performs an upward directory traversal to detect the IDE home. When test projects in src/test/resources/ide-projects/* lack proper IDE structure (missing workspaces or settings folders), the search continues beyond the test project boundaries and can accidentally discover and use the developer's actual IDEasy installation.

This causes:

• Different behavior between local and GitHub Actions environments (where no IDEasy installation exists outside the test)
• Risk of corrupting the developer's IDEasy setup during test execution
• False test results based on the developer's environment rather than isolated test data
• Difficult debugging as tests pass locally but fail in CI/CD

The issue was discovered when PR #1578 showed different behavior in GitHub Actions compared to local execution.

Reproduce

1. Set up an IDEasy development environment with the IDEasy repository cloned inside an active IDEasy installation
2. Create or run a test using AbstractIdeContextTest#newContext() with a test project that has incomplete IDE structure (e.g., missing workspaces or settings folders)
3. The test context creation will traverse up from the test project directory
4. If IDE_ROOT environment variable is not set, it will continue past the test boundary
5. It will find and use the developer's IDEasy installation instead of staying isolated to the test project

Example scenario:

/path/to/ideasy-dev/              ← Developer's IDEasy installation
  workspaces/
    main/
      IDEasy/                      ← IDEasy source code
        cli/src/test/resources/
          ide-projects/
            my-test/               ← Test project (incomplete structure)

When creating a context for my-test, the search traverses up and finds ideasy-dev as IDE_HOME instead of staying within the test boundaries.

Expected behavior

Test contexts should be strictly isolated and never use the developer's IDEasy installation:

1. Test context creation should have clear boundaries that prevent upward traversal beyond the test project root
2. An assertion or safety check should verify that tests never accidentally use a developer's IDE installation
3. Tests should behave consistently across all environments (local development, CI/CD, etc.)
4. The developer's IDEasy setup should be protected from any modifications during test execution

IDEasy status

This is an internal development issue that affects IDEasy contributors. The issue occurs during test execution in the IDEasy development environment itself, not in end-user IDEasy installations.

Environment where issue was discovered:

• Running JUnit tests locally as an IDEasy developer
• IDEasy source repository cloned within an active IDEasy installation
• Tests executing via Maven or IDE test runners

Related/Dependent issues

Related to PR #1578 where this behavior difference was first observed between local and GitHub Actions execution.

Comments/Hints

Current partial protection:
Line 188 in AbstractIdeContext checks getIdeRootPathFromEnv(false) and uses it at line 201 to limit traversal, but this only works if IDE_ROOT is explicitly set.

Proposed solution approach:

1. Add a test boundary marker (system property ide.test.root.boundary) set by AbstractIdeTestContext
2. Check this boundary during IDE home detection in AbstractIdeContext constructor
3. Add assertion in test context to verify test isolation
4. Add trace logging to show where and why the search stopped

This ensures test isolation without affecting production code behavior.