Implement project-based testing architecture for multi-project workspaces

[Copilot]

Adds infrastructure to support multiple Python projects (each with distinct Python executables and test configurations) within a single VS Code workspace. Currently behind a feature flag (useProjectBasedTesting = false) for safe deployment.

Core Infrastructure

• ProjectAdapter interface: Encapsulates project identity, Python environment, test adapters, and discovery state
• Project-scoped test IDs: Format {projectId}::{testPath} prevents ID collisions between projects
• Utility functions: Project ID generation via hash, nested project detection, ID scoping/parsing
• WorkspaceDiscoveryState: Temporary state for overlap detection and ownership resolution during discovery

Result Resolver Updates

• Added optional projectId parameter to PythonResultResolver constructor
• When present, prefixes all test IDs with project scope; when absent, uses legacy IDs (backward compatible)
• Updated populateTestTree() and TestDiscoveryHandler to propagate project scoping

Project Discovery Integration

• discoverWorkspaceProjects(): Queries Python Environment API for projects, filters to workspace, creates ProjectAdapter instances
• createProjectAdapter(): Resolves Python environment, creates project-scoped resolver and provider-specific adapters
• createDefaultProject(): Fallback that mimics single-workspace behavior using workspace interpreter
• State tracking maps:
  • workspaceProjects: Project registry by workspace URI
  • vsIdToProject: O(1) test-to-project lookup for execution
  • fileUriToProject: File-to-project mapping for file watching
  • projectToVsIds: Project-to-tests mapping for cleanup

Activation Flow

public async activate(): Promise<void> {
    if (this.useProjectBasedTesting) {
        // New: Discover projects via Python Environment API
        const projects = await this.discoverWorkspaceProjects(workspace.uri);
        this.workspaceProjects.set(workspace.uri, projectsMap);
    } else {
        // Legacy: Single WorkspaceTestAdapter per workspace
        this.activateLegacyWorkspace(workspace);
    }
}

Graceful degradation: Any failure in project discovery automatically falls back to legacy single-workspace mode. All new code paths are disabled by default until Phases 3-4 (discovery with overlap resolution, test execution) are implemented.

Files Changed

New:

• testController/common/projectAdapter.ts - Type definitions
• testController/common/projectUtils.ts - Utilities

Modified:

• testController/controller.ts - Project discovery and state management
• testController/common/resultResolver.ts - Project scoping support
• testController/common/testDiscoveryHandler.ts - Scoped error nodes
• testController/common/utils.ts - Scoped test ID creation

Original prompt

ok great! now.... do this and implement it please! you got this

[Chronological Review: The conversation began with the user asking about how control keeps different workspaces separate during creation and discovery. This led to a deeper investigation into how results from adapters appear in the UI. The user then proposed implementing a new feature allowing multiple projects per workspace, detailing the hierarchy of workspaces, projects, and tests. The user explored the implications of using the resultResolver and discussed the structure of project objects and their connection to workspaces. The conversation evolved to address potential issues with multiple resultResolvers, the use of a comprehensive API for mapping URIs to executables, and a complex discovery scenario involving overlapping projects. The user requested a markdown document summarizing the design, which was created and subsequently updated based on user feedback. The user then posed several questions and directives regarding error handling, settings, and project management, leading to a final request for implementation.]

[Intent Mapping: The user explicitly requested explanations of workspace separation, project organization, and the role of resultResolvers. They sought to clarify the structure of project objects and how to manage state across multiple layers. The user also aimed to create a design document to guide future implementation and requested updates based on specific notes and questions.]

[Technical Inventory: Key technologies discussed include the VSCode API for managing workspaces and projects, Python executables for project execution, and the resultResolver for handling test results. The conversation also touched on the use of absolute paths and cancellation tokens for managing test runs.]

[Code Archaeology: The user referenced the file /Users/eleanorboyd/vscode-python/src/client/testing/testController/controller.ts for ongoing modifications. They also mentioned the markdown document located at /Users/eleanorboyd/vscode-python/docs/project-based-testing-design.md, which was created to summarize the design discussions.]

[Progress Assessment: The user has successfully outlined the project structure and its relationship to workspaces, discussed the handling of overlapping test results, and created a design document. They have also provided specific directives for error handling and project settings.]

[Context Validation: All critical information for continuation is captured, including the structure of projects, the role of resultResolvers, and the handling of settings and errors.]

[Recent Commands Analysis: The last agent commands involved updating the markdown document based on user notes and questions. The user provided a series of directives regarding error handling, project settings, and implementation details. The immediate pre-summarization state involved preparing to implement the discussed features based on the updated design document.]

1. Conversation Overview: - Primary Objectives: The user requested explanations on workspace separation, project organization, and the role of resultResolvers. They aimed to create a design document to guide future implementation. - Session Context: The conversation flowed from initial inquiries about workspace management to detailed discussions on project structures, error handling, and the creation of a design document. - User Intent Evolution: The user's needs evolved from understanding existing structures to defining new features and implementation strategies.

2. Technical Foundation:

• VSCode API: Used for managing workspaces and projects.
• Python Executables: Associated with each project for execution.
• ResultResolver: Handles test results and overlaps.

3. Codebase Status:

• File Name: /Users/eleanorboyd/vscode-python/src/client/testing/testController/controller.ts
• Purpose: Central controller for managing test execution and results.
• Current State: Ongoing modifications to implement project-based testing features.
• Key Code Segments: Discussions around managing state and handling results.
• Dependencies: Relies on the VSCode API and Python executables.

4. Problem Resolution:

• Issues Encountered: Managing overlapping test results and ensuring proper project associations.
• Solutions Implemented: Defined structures for projects and their relationships to workspaces.
• Debugging Context: Ongoing discussions about error handling and settings management.
• Lessons Learned: Importance of clear project structures and effective error messaging.

5. Progress Tracking:

• Completed Tasks: Defined project structures and created a design document.
• Partially Complete Work: Implementation of discussed features is pending.
• Validated Outcomes: Clear understanding of workspace and project relationships.

6. Active Work State:

• Current Focus: Preparing to implement features based on the updated design document.
• Recent Context: User provide...

Created from VS Code.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.