[EPIC] Refactor and Improve E2E Test Execution

[josecelano]

Overview

This epic focuses on standardizing, documenting, and improving the End-to-End (E2E) test execution infrastructure to make it more consistent, maintainable, and easier for AI agents to execute. The work involves refactoring the current mixed approach to E2E testing into a unified, black-box testing strategy that uses the application's public CLI interface.

Current Situation

Terminology: E2E vs Rust Test Types

We use "E2E" (End-to-End) as our testing level terminology - the goal is to test at the end-user level via the public CLI interface. This is independent of Rust's test implementation types (unit tests vs integration tests).

• True E2E tests: Test via public CLI (black-box, end-user level)
• Temporary integration tests: Called "E2E" but currently test at application layer level because presentation commands don't exist yet

Test Files

We currently have 6 E2E test files with different Rust implementations:

Rust Integration Tests (newer, true E2E approach):

• tests/e2e_create_command.rs - Tests via public CLI
• tests/e2e_destroy_command.rs - Tests via public CLI

Explicit Binaries (older, temporary integration test approach):

• src/bin/e2e_config_tests.rs - Calls application layer directly
• src/bin/e2e_provision_and_destroy_tests.rs - Calls application layer directly
• src/bin/e2e_tests_full.rs - Calls application layer directly

The Rust integration tests use the public CLI interface (true black-box E2E testing), while the explicit binary tests call internal application layer handlers directly (temporary integration tests). This inconsistency creates maintenance challenges and makes it harder for contributors and AI agents to understand the testing approach.

Why this split exists: The explicit binary tests were created first, before presentation layer commands existed. The Rust integration tests were added later following the inside-outside development strategy. The explicit binaries are intended to be E2E but are temporarily integration tests until presentation commands are available.

Infrastructure split: Some tests use VMs (production-like), others use Docker (for GitHub Actions compatibility due to networking issues).

Goals

• Standardize all E2E tests to use black-box testing via public CLI
• Document different types of E2E tests and their purposes
• Make E2E tests easier for AI agents to understand and execute
• Improve test maintainability by decoupling from internal layers
• Provide clear guidelines for future E2E test development

Sub-Issues

This epic is broken down into sub-issues:

• [EPIC] Create Dependency Installation Package for E2E Tests #113 - Create Dependency Installation Package for E2E Tests (10-14 hours)
  • Create Detection Logic Package #114 - Create Detection Logic Package (2-3 hours)
  • Create CLI Binary with Check Command #115 - Create CLI Binary with Check Command (2-3 hours)
  • Create Docker Test Infrastructure #116 - Create Docker Test Infrastructure (2-3 hours)
  • Implement Installation Logic #117 - Implement Installation Logic (4-5 hours)
• Integrate Dependency Installer with E2E Tests #118 - Integrate Dependency Installer with E2E Tests (3-5 hours)
• Update CI Workflows and Remove Bash Scripts #119 - Update CI Workflows and Remove Bash Scripts (2-4 hours)
• Configure GitHub Copilot Agent Environment #120 - Configure GitHub Copilot Agent Environment (2-3 hours)
• Install Git Pre-Commit Hooks for Copilot Agent #121 - Install Git Pre-Commit Hooks for Copilot Agent (2-3 hours)
• Update Pre-Commit Script for GitHub Runner-Compatible E2E Tests #146 - Update Pre-Commit Script for GitHub Runner-Compatible E2E Tests (1-1.5 hours)
• Configure Copilot Agent Firewall for Dependency Installer #147 - Configure Copilot Agent Firewall for Dependency Installer (0.75-1.5 hours)

Total Estimated Time: 22.75-35 hours split across multiple focused sub-issues

Specification

See detailed specification: docs/issues/112-epic-refactor-and-improve-e2e-test-execution.md