E2E Test
crc-org/crc
Run CRC end-to-end tests for specific features and operating systems
A skill your agent uses when creating, modifying, debugging, or reviewing Aspire CLI end-to-end tests that use Hex1b terminal automation under tests/Aspire.Cli.EndToEnd.Tests/.
$ npx skills add microsoft/aspire --skill cli-e2e-testing -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install microsoft/aspire cli-e2e-testing --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/microsoft/aspire.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/cli-e2e-testing .claude/skills/cli-e2e-testing && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "cli-e2e-testing" agent skill from https://github.com/microsoft/aspire/tree/main/.agents/skills/cli-e2e-testing into .claude/skills/cli-e2e-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "cli-e2e-testing", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/microsoft/aspire/tree/main/.agents/skills/cli-e2e-testingType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add microsoft/aspire --skill cli-e2e-testing -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install microsoft/aspire cli-e2e-testing --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/microsoft/aspire.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.agents/skills/cli-e2e-testing .agents/skills/cli-e2e-testing && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "cli-e2e-testing" agent skill from https://github.com/microsoft/aspire/tree/main/.agents/skills/cli-e2e-testing into .agents/skills/cli-e2e-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "cli-e2e-testing", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add microsoft/aspire --skill cli-e2e-testing -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install microsoft/aspire cli-e2e-testing --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/microsoft/aspire.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.agents/skills/cli-e2e-testing .cursor/skills/cli-e2e-testing && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "cli-e2e-testing" agent skill from https://github.com/microsoft/aspire/tree/main/.agents/skills/cli-e2e-testing into .cursor/skills/cli-e2e-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "cli-e2e-testing", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/microsoft/aspire.git --path .agents/skills/cli-e2e-testing--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add microsoft/aspire --skill cli-e2e-testing -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install microsoft/aspire cli-e2e-testing --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/microsoft/aspire.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.agents/skills/cli-e2e-testing .gemini/skills/cli-e2e-testing && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "cli-e2e-testing" agent skill from https://github.com/microsoft/aspire/tree/main/.agents/skills/cli-e2e-testing into .gemini/skills/cli-e2e-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "cli-e2e-testing", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install microsoft/aspire cli-e2e-testingInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add microsoft/aspire --skill cli-e2e-testing -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/microsoft/aspire.git skills-src && mkdir -p .github/skills && cp -r skills-src/.agents/skills/cli-e2e-testing .github/skills/cli-e2e-testing && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "cli-e2e-testing" agent skill from https://github.com/microsoft/aspire/tree/main/.agents/skills/cli-e2e-testing into .github/skills/cli-e2e-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "cli-e2e-testing", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add microsoft/aspire --skill cli-e2e-testing -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install microsoft/aspire cli-e2e-testing --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/microsoft/aspire.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.agents/skills/cli-e2e-testing .opencode/skills/cli-e2e-testing && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "cli-e2e-testing" agent skill from https://github.com/microsoft/aspire/tree/main/.agents/skills/cli-e2e-testing into .opencode/skills/cli-e2e-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "cli-e2e-testing", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
cli-e2e-testingA skill your agent uses when creating, modifying, debugging, or reviewing Aspire CLI end-to-end tests that use Hex1b terminal automation under tests/Aspire.Cli.EndToEnd.Tests/.
CLI E2E Testing is an agent skill from microsoft/aspire, published by the product's own GitHub organization. Use when creating, modifying, debugging, or reviewing Aspire CLI end-to-end tests that use Hex1b terminal automation under tests/Aspire.Cli.EndToEnd.Tests/.
Its SKILL.md is about 8.6k tokens, which your agent loads only when the skill is triggered. The skill folder holds 1 other file (for example `troubleshooting.md`).
It sits in Testing & QA, covering End-to-end testing. It works with Linux. The repository describes itself as: Aspire is the tool for code-first, extensible, observable dev and deploy. The licence is MIT.
3 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit 809a672. It shows what the files ask for, not the result of running them.
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Shell commands in SKILL.md call:
dotnetghgitFrom the folder's file list and the shell code blocks in SKILL.md.
No URLs in SKILL.md. Its commands use gh and git, which can reach the network depending on how they are called.
From URLs in SKILL.md, links to its own repository left out.
Names these keys or tokens, usually read from environment variables:
GH_TOKENFrom names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
CLI E2E Testing loads about 8.6k tokens when it runs. Until then it costs about 43 tokens; SKILL.md has 2,291 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
The full file from microsoft/aspire at commit 809a672, republished under its MIT licence (© microsoft). 2,291 words, ~8,571 tokens.
.claude/skills/cli-e2e-testing/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.This skill provides patterns and practices for writing end-to-end tests for the Aspire CLI using the Hex1b terminal automation library.
CLI E2E tests use the Hex1b library to automate terminal sessions, simulating real user interactions with the Aspire CLI. Tests run in CI with asciinema recordings for debugging.
Location: tests/Aspire.Cli.EndToEnd.Tests/
Supported Platforms: Linux only. Hex1b requires a Linux terminal environment. Tests are configured to skip on Windows and macOS in CI.
Hex1bTerminal: The main terminal class from the Hex1b library for terminal automationHex1bTerminalAutomator: Async/await API for driving a Hex1bTerminal — the preferred approach for new testsHex1bAutomatorTestHelpers (shared helpers): Async extension methods on Hex1bTerminalAutomator (WaitForSuccessPromptAsync, AspireNewAsync, etc.)CliE2EAutomatorHelpers (Helpers/CliE2EAutomatorHelpers.cs): CLI-specific async extension methods on Hex1bTerminalAutomator (PrepareDockerEnvironmentAsync, InstallAspireCliAsync, etc.)CellPatternSearcher: Pattern matching for terminal cell contentSequenceCounter (Helpers/SequenceCounter.cs): Tracks command execution count for deterministic prompt detectionCliE2ETestHelpers (Helpers/CliE2ETestHelpers.cs): Environment variable helpers and terminal factory methodsTemporaryWorkspace: Creates isolated temporary directories for test executionHex1bTerminalInputSequenceBuilder (legacy): Fluent builder API for building sequences of terminal input/output operations. Prefer Hex1bTerminalAutomator for new tests.Each test:
TemporaryWorkspace for isolationHex1bTerminal with headless mode and asciinema recordingHex1bTerminalAutomator wrapping the terminalpublic sealed class SmokeTests(ITestOutputHelper output)
{
[Fact]
public async Task MyCliTest()
{
var repoRoot = CliE2ETestHelpers.GetRepoRoot();
var strategy = CliInstallStrategy.Detect(output.WriteLine);
var workspace = TemporaryWorkspace.Create(output);
using var terminal = CliE2ETestHelpers.CreateDockerTestTerminal(repoRoot, strategy, output, workspace: workspace);
var counter = new SequenceCounter();
var auto = new Hex1bTerminalAutomator(terminal, defaultTimeout: TimeSpan.FromSeconds(500));
await using var terminalRun = CliE2ETestHelpers.StartRun(terminal, workspace, auto, counter, output, TestContext.Current.CancellationToken);
await auto.PrepareDockerEnvironmentAsync(counter, workspace);
await auto.InstallAspireCliAsync(strategy, counter);
await auto.TypeAsync("aspire --version");
await auto.EnterAsync();
await auto.WaitForSuccessPromptAsync(counter);
}
}Always use CliE2ETestHelpers.StartRun to wrap the terminal run. This returns a TerminalRun (implements IAsyncDisposable) that automatically:
CaptureAspireDiagnosticsAsync (best effort)exit and presses Enter to close the terminalThis eliminates the need for manual exit/await pendingRun at the end of every test and ensures diagnostics are always captured, even when tests fail.
// DO: Use StartRun for consistent diagnostics capture and cleanup
using var terminal = CliE2ETestHelpers.CreateDockerTestTerminal(repoRoot, strategy, output, workspace: workspace);
var counter = new SequenceCounter();
var auto = new Hex1bTerminalAutomator(terminal, defaultTimeout: TimeSpan.FromSeconds(500));
await using var terminalRun = CliE2ETestHelpers.StartRun(terminal, workspace, auto, counter, output, TestContext.Current.CancellationToken);
// ... test body — no exit/pendingRun needed at the end
// DON'T: Manually handle exit and pendingRun
var pendingRun = terminal.RunAsync(TestContext.Current.CancellationToken);
// ... test body ...
await auto.TypeAsync("exit");
await auto.EnterAsync();
await pendingRun;CLI E2E tests run inside Docker containers on Linux. The workflow is: build a portable archive with localhive, then point the tests at it. This is the primary way to iterate on E2E tests during development.
./restore.sh or .\restore.cmd)# 1. Build a portable archive with CLI + packages + bundle
# Use linux-arm64 on Apple Silicon, linux-x64 on Intel/Linux
./localhive.sh -o /tmp/aspire-e2e -r linux-arm64 --archive
# 2. Run a specific test
ASPIRE_E2E_ARCHIVE=/tmp/aspire-e2e.tar.gz \
dotnet test tests/Aspire.Cli.EndToEnd.Tests/Aspire.Cli.EndToEnd.Tests.csproj \
-- --filter-method "*.CreateAndRunAspireStarterProject"
# 3. Run all tests in a class
ASPIRE_E2E_ARCHIVE=/tmp/aspire-e2e.tar.gz \
dotnet test tests/Aspire.Cli.EndToEnd.Tests/Aspire.Cli.EndToEnd.Tests.csproj \
-- --filter-class "*.SmokeTests"# 1. Build a portable archive (Docker Desktop uses linux-x64 via WSL2)
.\localhive.ps1 -o C:\tmp\aspire-e2e -r linux-x64 -Archive
# 2. Run a specific test
$env:ASPIRE_E2E_ARCHIVE = "C:\tmp\aspire-e2e.tar.gz"
dotnet test tests\Aspire.Cli.EndToEnd.Tests\Aspire.Cli.EndToEnd.Tests.csproj `
-- --filter-method "*.CreateAndRunAspireStarterProject"
# 3. Run all tests in a class
dotnet test tests\Aspire.Cli.EndToEnd.Tests\Aspire.Cli.EndToEnd.Tests.csproj `
-- --filter-class "*.SmokeTests"The archive must match the Docker container's architecture:
| Host | Docker Desktop | RID |
|---|---|---|
| Apple Silicon Mac | Linux arm64 containers | linux-arm64 |
| Intel Mac | Linux x64 containers | linux-x64 |
| Windows (any) | WSL2 Linux x64 | linux-x64 |
| Linux x64 | Native | linux-x64 |
| Linux arm64 | Native | linux-arm64 |
The typical loop when writing or debugging E2E tests:
# 1. Make your code changes (CLI, hosting, templates, etc.)
# 2. Rebuild the archive (picks up all changes — ~3 min)
./localhive.sh -o /tmp/aspire-e2e -r linux-arm64 --archive
# 3. Run the specific test you're working on
ASPIRE_E2E_ARCHIVE=/tmp/aspire-e2e.tar.gz \
dotnet test tests/Aspire.Cli.EndToEnd.Tests/Aspire.Cli.EndToEnd.Tests.csproj \
-- --filter-method "*.YourTestName"
# 4. If it fails, check the asciinema recording
# Recordings are saved under the test output TestResults/recordings/ directory
# Play with: asciinema play /path/to/YourTestName.cast
# 5. Fix and repeat from step 1 or 2The CliInstallStrategy class auto-detects how to install the CLI in the test container. You can override via environment variables:
| Env Var | Mode | Example |
|---|---|---|
ASPIRE_E2E_ARCHIVE | LocalHive — extract archive into container | /tmp/aspire-e2e.tar.gz |
ASPIRE_E2E_QUALITY | Install script with quality | dev, staging, release |
ASPIRE_E2E_VERSION | Install script with version | 13.2.1 |
| (none, in CI) | PullRequest — install from PR artifacts | Auto-detected |
| (none, locally) | InstallScript (latest GA) | Auto-detected |
LocalHive (via ASPIRE_E2E_ARCHIVE) is the recommended mode for local development — it uses your locally-built CLI, packages, and bundle so you test exactly what you've changed.
Useful for verifying tests pass against shipped versions or catching regressions:
# Test against latest GA release
ASPIRE_E2E_QUALITY=release dotnet test tests/Aspire.Cli.EndToEnd.Tests/Aspire.Cli.EndToEnd.Tests.csproj \
-- --filter-method "*.CreateAndRunAspireStarterProject"
# Test against daily builds
ASPIRE_E2E_QUALITY=dev dotnet test ...
# Test against a specific version
ASPIRE_E2E_VERSION=13.2.1 dotnet test ...A set of tests validates the CLI identity sidecar — the ability to make a locally built CLI
emulate a different channel/version via ASPIRE_CLI_* env vars. They form an AppHost-language ×
channel-emulation matrix (one test per language because C# and TypeScript scaffold through different
code paths and have diverged before):
| Class | Channel emulated | Aspire* source | NuGet.config dropped? |
|---|---|---|---|
EmulatedReleasedBuildTests | stable (latest shipped) | nuget.org | No (C# and TS) |
EmulatedStagingBuildTests | staging (latest darc build) | darc-pub-... feed | Yes — darc feed pin |
EmulatedLocalReleaseBuildTests | stable (future, local-only) | local hive via ASPIRE_CLI_PACKAGES | No (C# and TS) |
EmulatedLocalReleaseBuildTests is the all-local "future release" row: it emulates a version
(e.g. 13.5.0) that exists only in a locally built hive, so a successful resolve proves the CLI
consulted ASPIRE_CLI_PACKAGES rather than nuget.org. Run it by building a stable-shaped archive
with localhive --version:
# 1. Build a stable-shaped archive (note: --version X.Y.Z, NOT a prerelease suffix)
./localhive.sh --version 13.5.0 -o /tmp/aspire-localrelease -r linux-arm64 --archive
# 2. Run the all-local class
ASPIRE_E2E_ARCHIVE=/tmp/aspire-localrelease.tar.gz \
dotnet test --project tests/Aspire.Cli.EndToEnd.Tests/Aspire.Cli.EndToEnd.Tests.csproj \
-- --filter-class "*.EmulatedLocalReleaseBuildTests"These tests skip unless the CLI was installed from a LocalHive archive and that archive is
stable-shaped (no prerelease suffix). In default CI the archive is a prerelease LocalArchive, so they
skip and add zero CI cost — CI relies on --ignore-exit-code 8 (set in eng/Testing.targets
MtpBaseArgs) so an all-skipped class job still passes. The test also registers the hive as an
ambient NuGet source (dotnet nuget add source) because MSBuild resolves the apphost's
Aspire.AppHost.Sdk before restore from nuget.config sources only, ignoring ASPIRE_CLI_PACKAGES.
⚠️ Local rebuilds: isolate the NuGet global cache. This only affects local iteration of a stable-shaped emulation (the E2E tests run in fresh Docker containers, so CI is immune). NuGet's global packages folder (
~/.nuget/packages/<id>/<version>/) caches extracted packages keyed by version. When you emulate a fixed stable version (e.g.13.5.0) and rebuild it, a stale13.5.0in that shared cache silently shadows the freshly built one — same version, different content — so restore drifts (the stale AppHost SDK injects a prerelease floor and you getNU1603warnings binding the graph to a stray13.5.0-pr.…). Fix: pointNUGET_PACKAGESat a per-emulation directory (export NUGET_PACKAGES=/tmp/aspire-localrelease/.nuget-packages).localhive … -o DIR's generatedactivate.sh/activate.ps1already sets this up. See the cache hazard note in.agents/skills/cli-channel-debugging/SKILL.md(Scenario 7c) for the full mechanism.
The SequenceCounter class tracks the number of shell commands executed. This enables deterministic waiting for command completion via a custom shell prompt.
PrepareDockerEnvironmentAsync() configures the shell with a custom prompt: [N OK] $ or [N ERR:code] $ WaitForSuccessPromptAsync(counter) waits for a prompt showing the current count with OKvar counter = new SequenceCounter();
var auto = new Hex1bTerminalAutomator(terminal, defaultTimeout: TimeSpan.FromSeconds(500));
await auto.PrepareDockerEnvironmentAsync(counter, workspace); // Sets up prompt, counter starts at 1
await auto.TypeAsync("echo hello");
await auto.EnterAsync();
await auto.WaitForSuccessPromptAsync(counter); // Waits for "[1 OK] $ ", then increments to 2
await auto.TypeAsync("ls -la");
await auto.EnterAsync();
await auto.WaitForSuccessPromptAsync(counter); // Waits for "[2 OK] $ ", then increments to 3
await auto.TypeAsync("exit");
await auto.EnterAsync();This approach is more reliable than arbitrary timeouts because it deterministically waits for each command to complete.
Use CellPatternSearcher to find text patterns in terminal output:
// Simple text search (literal string matching - PREFERRED)
var waitingForPrompt = new CellPatternSearcher()
.Find("Enter the project name");
// Literal string with special characters (use Find, not FindPattern!)
var waitingForTemplate = new CellPatternSearcher()
.Find("> Starter App (FastAPI/React)"); // Parentheses and slashes are literal
// Regex pattern (only when you need wildcards/regex features)
var waitingForAnyStarter = new CellPatternSearcher()
.FindPattern("> Starter App.*"); // .* matches anything
// Chained patterns (find "b", then scan right until "$", then right of " ")
var waitingForShell = new CellPatternSearcher()
.Find("b").RightUntil("$").Right(' ').Right(' ');
// Use in WaitUntilAsync
await auto.WaitUntilAsync(
snapshot => waitingForPrompt.Search(snapshot).Count > 0,
TimeSpan.FromSeconds(30),
description: "waiting for prompt");Find(string): Literal string matching. Use this for most cases.FindPattern(string): Regex pattern matching. Use only when you need regex features like wildcards.Important: If your search string contains regex special characters like (, ), /, ., *, +, ?, [, ], {, }, ^, $, |, or \, use Find() instead of FindPattern() to avoid regex interpretation.
| Method | Description |
|---|---|
WaitForSuccessPromptAsync(counter, timeout?) | Waits for [N OK] $ prompt, fails immediately if error prompt appears, and increments counter |
WaitForAnyPromptAsync(counter, timeout?) | Waits for any prompt (OK or ERR) and increments counter |
WaitForErrorPromptAsync(counter, timeout?) | Waits for [N ERR:code] $ prompt and increments counter |
RunCommandAsync(command, counter, timeout?) | Types a command, presses Enter, and waits for success prompt (fails fast on error) |
DeclineAgentInitPromptAsync() | Declines the aspire agent init prompt if it appears |
AspireNewAsync(projectName, counter, template?, useRedisCache?) | Runs aspire new interactively, handling template selection, project name, output path, URLs, Redis, and test project prompts |
See AspireNew Helper below for detailed usage.
| Method | Description |
|---|---|
PrepareDockerEnvironmentAsync(counter, workspace) | Sets up Docker container environment with custom prompt and command tracking |
InstallAspireCliAsync(installMode, counter) | Installs the Aspire CLI inside the Docker container |
ClearScreenAsync(counter) | Clears the terminal screen and waits for prompt |
| Method | Description |
|---|---|
IncrementSequence(counter) | Manually increments the counter |
The following extensions on Hex1bTerminalInputSequenceBuilder are still available but should not be used in new tests:
| Method | Description |
|---|---|
WaitForSuccessPrompt(counter, timeout?) | (legacy) Waits for [N OK] $ prompt and increments counter |
PrepareEnvironment(workspace, counter) | (legacy) Sets up custom prompt with command tracking |
SourceAspireBundleEnvironment(counter) | (legacy) Sources bundle PATH environment variables |
Wait for specific output patterns rather than arbitrary delays:
var waitingForMessage = new CellPatternSearcher()
.Find("Project created successfully.");
await auto.TypeAsync("aspire new");
await auto.EnterAsync();
await auto.WaitUntilAsync(
s => waitingForMessage.Search(s).Count > 0,
TimeSpan.FromMinutes(2),
description: "waiting for project created message");After running shell commands, use WaitForSuccessPromptAsync() to wait for the command to complete:
await auto.TypeAsync("dotnet build");
await auto.EnterAsync();
await auto.WaitForSuccessPromptAsync(counter); // Waits for prompt, verifies success
await auto.TypeAsync("dotnet run");
await auto.EnterAsync();
await auto.WaitForSuccessPromptAsync(counter);The AspireNew extension method centralizes the multi-step aspire new interactive flow. Use it instead of manually building the prompt sequence.
| Value | Template | Arrow Keys |
|---|---|---|
Starter (default) | Starter App (Blazor) | None (first option) |
JsReact | Starter App (ASP.NET Core/React) | Down ×1 |
PythonReact | Starter App (FastAPI/React) | Down ×2 |
ExpressReact | Starter App (Express/React) | Down ×3 |
EmptyAppHost | Empty AppHost | Down ×4 |
| Parameter | Default | Description |
|---|---|---|
projectName | (required) | Project name typed at the prompt |
counter | (required) | SequenceCounter for prompt tracking |
template | AspireTemplate.Starter | Which template to select |
useRedisCache | true | Accept Redis (Enter) or decline (Down+Enter). Only applies to Starter, JsReact, PythonReact. |
// Starter template with defaults (Redis=Yes, TestProject=No)
await auto.AspireNewAsync("MyProject", counter);
// Starter template, no Redis
await auto.AspireNewAsync("MyProject", counter, useRedisCache: false);
// JsReact template, no Redis
await auto.AspireNewAsync("MyProject", counter, template: AspireTemplate.JsReact, useRedisCache: false);
// PythonReact template
await auto.AspireNewAsync("MyProject", counter,
template: AspireTemplate.PythonReact,
useRedisCache: false);
// Empty app host
await auto.AspireNewAsync("MyProject", counter, template: AspireTemplate.EmptyAppHost);For aspire new, use the AspireNewAsync helper instead of manually building the prompt sequence:
// DO: Use the helper
await auto.AspireNewAsync("MyProject", counter);
// DON'T: Manually build the sequence (this is what AspireNewAsync does internally)
var waitingForTemplatePrompt = new CellPatternSearcher()
.FindPattern("> Starter App");
var waitingForProjectNamePrompt = new CellPatternSearcher()
.Find("Enter the project name");
await auto.TypeAsync("aspire new");
await auto.EnterAsync();
await auto.WaitUntilAsync(
s => waitingForTemplatePrompt.Search(s).Count > 0,
TimeSpan.FromSeconds(30),
description: "waiting for template prompt");
await auto.EnterAsync();
await auto.WaitUntilAsync(
s => waitingForProjectNamePrompt.Search(s).Count > 0,
TimeSpan.FromSeconds(10),
description: "waiting for project name prompt");
await auto.TypeAsync("MyProject");
await auto.EnterAsync();For other interactive CLI commands, wait for each prompt before responding:
var waitingForPrompt = new CellPatternSearcher()
.Find("Enter your choice");
await auto.TypeAsync("aspire some-command");
await auto.EnterAsync();
await auto.WaitUntilAsync(
s => waitingForPrompt.Search(s).Count > 0,
TimeSpan.FromSeconds(30),
description: "waiting for choice prompt");
await auto.EnterAsync();For processes like aspire run that don't exit on their own:
using Hex1b.Input;
await auto.TypeAsync("aspire run");
await auto.EnterAsync();
await auto.WaitUntilAsync(
s => waitForCtrlCMessage.Search(s).Count > 0,
TimeSpan.FromSeconds(30),
description: "waiting for Ctrl+C message");
await auto.Ctrl().KeyAsync(Hex1bKey.C); // Send Ctrl+C
await auto.WaitForSuccessPromptAsync(counter);Some operations only apply in CI (like installing CLI from PR artifacts):
var installMode = CliInstallStrategy.Detect(output.WriteLine);
await auto.PrepareDockerEnvironmentAsync(counter, workspace);
await auto.InstallAspireCliAsync(installMode, counter);
// Continue with test commands...Use CliE2ETestHelpers for CI environment variables:
var prNumber = CliE2ETestHelpers.GetRequiredPrNumber(); // GITHUB_PR_NUMBER (0 when local)
var commitSha = CliE2ETestHelpers.GetRequiredCommitSha(); // GITHUB_PR_HEAD_SHA ("local0000" when local)
var isCI = CliE2ETestHelpers.IsRunningInCI; // true when both env vars setdescription: on WaitUntilAsyncEvery WaitUntilAsync call requires a named description: parameter. This description appears in logs and asciinema recordings to make debugging easier when a wait times out.
// DON'T: Missing description
await auto.WaitUntilAsync(
s => pattern.Search(s).Count > 0,
TimeSpan.FromSeconds(30));
// DO: Include a meaningful description
await auto.WaitUntilAsync(
s => pattern.Search(s).Count > 0,
TimeSpan.FromSeconds(30),
description: "waiting for build output");ExecuteCallback Was UsedThe old builder API used ExecuteCallback() to run synchronous operations mid-sequence. With the automator API, simply inline the code directly — no special wrapper is needed.
// Old builder API (DON'T use in new tests)
sequenceBuilder
.ExecuteCallback(() => File.WriteAllText(configPath, newConfig))
.Type("aspire run")
.Enter();
// Automator API (DO)
File.WriteAllText(configPath, newConfig);
await auto.TypeAsync("aspire run");
await auto.EnterAsync();Use WaitUntilAsync() with specific output patterns instead of arbitrary delays:
// DON'T: Arbitrary delays
await Task.Delay(TimeSpan.FromSeconds(30));
// DO: Wait for specific output
await auto.WaitUntilAsync(
snapshot => pattern.Search(snapshot).Count > 0,
TimeSpan.FromSeconds(30),
description: "waiting for expected output");Don't hard-code the sequence numbers in WaitForSuccessPromptAsync calls. Use the counter:
// DON'T: Hard-coded sequence numbers
await auto.WaitUntilAsync(
s => s.GetScreenText().Contains("[3 OK] $ "),
timeout,
description: "waiting for prompt");
// DO: Use the counter
await auto.WaitForSuccessPromptAsync(counter);The counter automatically tracks which command you're waiting for, even if command sequences change.
When writing new CLI E2E tests, use the Hex1b MCP server to interactively explore what terminal output to expect. The MCP server provides tools to start terminal sessions, send commands, and capture screenshots—helping you discover the exact strings and prompts to use in CellPatternSearcher.
aspire new or aspire run) and observe the outputCellPatternSearcher patternsaspire newAsk the MCP server to:
aspire new interactivelyThis reveals the exact strings like:
"> Starter App" for template selection"Enter the project name" for name input"Press Ctrl+C to stop..." for run completionCellPatternSearcher isn't matching, capture current terminal state to compareCapture Terminal Text to get plain text for pattern matchingCapture Terminal Screenshot (SVG) for visual debuggingWait for Terminal Text tool works similarly to WaitUntil in testsWhen adding new CLI operations as extension methods, define them on Hex1bTerminalAutomator:
internal static async Task MyNewOperationAsync(
this Hex1bTerminalAutomator auto,
string arg,
SequenceCounter counter,
TimeSpan? timeout = null)
{
var expectedOutput = new CellPatternSearcher()
.Find("Expected output");
await auto.TypeAsync($"aspire my-command {arg}");
await auto.EnterAsync();
await auto.WaitUntilAsync(
snapshot => expectedOutput.Search(snapshot).Count > 0,
timeout ?? TimeSpan.FromSeconds(30),
description: "waiting for expected output from my-command");
await auto.WaitForSuccessPromptAsync(counter);
}Key points:
Hex1bTerminalAutomatorSequenceCounter parameter for prompt trackingCellPatternSearcher for output detectiondescription: on WaitUntilAsync callsWaitForSuccessPromptAsync(counter) after command completionTask (no fluent chaining needed with async/await)Environment variables set in CI:
GITHUB_PR_NUMBER: PR number for downloading CLI artifactsGITHUB_PR_HEAD_SHA: PR head commit SHA for version verification (not the merge commit)GH_TOKEN: GitHub token for API accessGITHUB_WORKSPACE: Workspace root for artifact pathsEach test class runs as a separate CI job via the unified TestEnumerationRunsheetBuilder infrastructure (using SplitTestsOnCI=true) for parallel execution.
When CLI E2E tests fail in CI, follow these steps to diagnose the issue:
Flaky test investigation: for recurring/intermittent failures, see
troubleshooting.mdfor a catalog of known flake classes (Y/n input race, prompt-counter desync, etc.) and the recipes to identify them from.castrecordings.
For VS Code extension behavior or extension/CLI integration issues, strongly prefer adding or
updating a reproducible test under extension/src/test-e2e/. Use agent-driven Playwright/VS Code UI
driving only as exploratory diagnosis when the E2E scenario is not clear yet; convert any successful
manual reproduction into an E2E test before fixing the bug unless there is a strong, explicit reason
not to.
When running extension E2E tests against an older published CLI for compatibility validation, set
ASPIRE_EXTENSION_E2E_SKIP_CURRENT_CLI_REGRESSIONS=true to skip tests that intentionally cover bugs
fixed only by the current repo-built CLI.
VS Code extension E2E jobs upload shard-specific diagnostics as extension-e2e-diagnostics-<rid>-<shard>-attempt<N> artifacts. Linux shards include .mp4 display recordings from Xvfb by default; Windows shards do not record video and instead rely on screenshots, VS Code logs, state files, and workspace diagnostics.
# List VS Code extension E2E diagnostic artifacts for a run.
gh api "repos/microsoft/aspire/actions/runs/<run-id>/artifacts?per_page=100" --paginate \
--jq '.artifacts[] | select(.name | startswith("extension-e2e-diagnostics")) | "\(.size_in_bytes)\t\(.name)"'
# Download one shard's diagnostics. The artifact contains .mp4 recordings
# on Linux, .ffmpeg.log files, screenshots, VS Code logs, state files, and
# captured workspace diagnostics.
mkdir -p ./e2e-diagnostics && cd ./e2e-diagnostics
gh run download <run-id> --repo microsoft/aspire \
-n extension-e2e-diagnostics-linux-x64-<shard>-attempt<N> \
-D <shard>Important paths inside the downloaded shard:
<shard>/.test-recordings/<shard>/<runId>.mp4
<shard>/.test-recordings/<shard>/<runId>.ffmpeg.log
<shard>/.test-storage/**/screenshots/
<shard>/.test-results/e2e/<shard>/extension-state.jsonThe workflow keeps Linux recordings by default with ASPIRE_EXTENSION_E2E_RECORDING_MODE=always. Use failure to keep only failed-run videos or off to disable recording for local runs.
The fastest way to debug a CLI E2E test failure is to download and play the asciinema recording.
Using the helper scripts (recommended):
# Linux/macOS - Download and play recording from latest CI run on current branch
./eng/scripts/get-cli-e2e-recording.sh -p
# List available test recordings
./eng/scripts/get-cli-e2e-recording.sh -l
# Download specific test
./eng/scripts/get-cli-e2e-recording.sh -t SmokeTests -p
# Download from specific run
./eng/scripts/get-cli-e2e-recording.sh -r 20944531393 -p# Windows PowerShell
.\eng\scripts\get-cli-e2e-recording.ps1 -Play
# List available recordings
.\eng\scripts\get-cli-e2e-recording.ps1 -List
# Download specific test
.\eng\scripts\get-cli-e2e-recording.ps1 -TestName SmokeTests -Play
# Download from specific run
.\eng\scripts\get-cli-e2e-recording.ps1 -RunId 20944531393 -PlayManual download steps:
# List recent CI runs for your branch
gh run list --branch $(git branch --show-current) --workflow CI --limit 5
# Get the run ID from the output or use:
RUN_ID=$(gh run list --branch $(git branch --show-current) --workflow CI --limit 1 --json databaseId --jq '.[0].databaseId')
echo "Run ID: $RUN_ID"
echo "URL: https://github.com/microsoft/aspire/actions/runs/$RUN_ID"Job names follow the pattern: Tests / Cli E2E Linux (<TestClass>) / <TestClass> (ubuntu-latest)
Artifact names follow the pattern: logs-<TestClass>-ubuntu-latest
# Check if CLI E2E tests ran and their status
gh run view $RUN_ID --json jobs --jq '.jobs[] | select(.name | test("Cli E2E")) | {name, conclusion}'
# List available CLI E2E artifacts
gh api --paginate "repos/microsoft/aspire/actions/runs/$RUN_ID/artifacts" \
--jq '.artifacts[].name' | grep -i "smoke"# Download the artifact
mkdir -p /tmp/cli-e2e-debug
gh run download $RUN_ID -n logs-SmokeTests-ubuntu-latest -D /tmp/cli-e2e-debug
# Find the recording
find /tmp/cli-e2e-debug -name "*.cast"
# Play it (requires asciinema: pip install asciinema)
asciinema play /tmp/cli-e2e-debug/testresults/recordings/CreateAndRunAspireStarterProject.cast
# Or view raw content for AI analysis
head -100 /tmp/cli-e2e-debug/testresults/recordings/CreateAndRunAspireStarterProject.castDownloaded artifacts contain:
testresults/
├── <TestClass>_net10.0_*.trx # Test results XML
├── Aspire.Cli.EndToEnd.Tests_*.log # Console output log
├── *.crash.dmp # Crash dump (if test crashed)
├── test.binlog # MSBuild binary log
├── recordings/
│ ├── CreateAndRunAspireStarterProject.cast # Asciinema recording
│ └── ...
└── workspaces/ # Captured project workspaces (on failure)
└── TestClassName.MethodName/ # Full generated project for debugging
├── apphost.ts
├── aspire.config.json
├── .aspire/modules/ # Generated SDK - check aspire.js for exports
└── ...Tests annotated with [CaptureWorkspaceOnFailure] automatically copy the generated project workspace into the test artifacts when a test fails. This is invaluable for debugging template generation or aspire run failures — you can inspect the exact generated files including the SDK output in .aspire/modules/aspire.js.
To add workspace capture to a new test:
[Fact]
[CaptureWorkspaceOnFailure]
public async Task MyTemplateTest()
{
var workspace = TemporaryWorkspace.Create(output);
// ... test code — workspace is automatically registered for capture ...
}
### One-Liner: Download Latest Recording
```bash
# Download and play the latest CLI E2E recording from current branch
RUN_ID=$(gh run list --branch $(git branch --show-current) --workflow CI --limit 1 --json databaseId --jq '.[0].databaseId') && \
rm -rf /tmp/cli-e2e-debug && mkdir -p /tmp/cli-e2e-debug && \
gh run download $RUN_ID -n logs-SmokeTests-ubuntu-latest -D /tmp/cli-e2e-debug && \
CAST=$(find /tmp/cli-e2e-debug -name "*.cast" | head -1) && \
echo "Recording: $CAST" && \
asciinema play "$CAST"| Symptom | Likely Cause | Solution |
|---|---|---|
| Timeout waiting for prompt | Command failed or hung | Check recording to see terminal output at timeout |
[N ERR:code] $ in prompt | Previous command exited with non-zero | Check recording to see which command failed |
| Pattern not found | Output format changed | Update CellPatternSearcher patterns |
| Pattern not found but text is visible | Using FindPattern with regex special chars | Use Find() instead of FindPattern() for literal strings containing (, ), /, etc. |
| Test hangs indefinitely | Waiting for wrong prompt number | Verify SequenceCounter usage matches commands |
| Timeout waiting for dashboard URL | Project failed to build/run | Check recording for build errors |
© microsoft, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
SKILL.md and 1 other file in .agents/skills/cli-e2e-testing of microsoft/aspire.
Open the folder on GitHubat commit 809a672
CLI E2E Testing next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| CLI E2E Testing this skillmicrosoft/aspire | 6.3k | — | ~8.6k | Automated safety check: Pass | MIT | |
| E2E Testcrc-org/crc | 1.4k | — | ~3.3k | Automated safety check: Notes | Apache-2.0 | |
| Openclaw Parallels SmokeSafeAI-Lab-X/ClawKeeper | 1k | — | ~1.1k | Automated safety check: Pass | None | |
| Cross Platform Gui E2E TestStudentWeis/ropy | 193 | — | ~1.9k | Automated safety check: Pass | MIT | |
| Build Imageskubernetes-sigs/cloud-provider-azure | 294 | — | ~1.7k | Automated safety check: Pass | Apache-2.0 | |
| Testing Livepeerdaydreamlive/scope | 452 | — | ~2.5k | Automated safety check: Pass | Custom licence |
crc-org/crc
Run CRC end-to-end tests for specific features and operating systems
SafeAI-Lab-X/ClawKeeper
End-to-end Parallels smoke, upgrade, and rerun workflow for OpenClaw across macOS, Windows, and Linux guests.
StudentWeis/ropy
Run packaged Ropy desktop GUI end-to-end, smoke, and compatibility tests across macOS, Windows, and Linux.
kubernetes-sigs/cloud-provider-azure
Build cloud-provider-azure container images through the repo Makefile with explicit IMAGETAG and IMAGEREGISTRY inputs, optional make flag overrides, and opt-in bounded Docker or Podman retries.
daydreamlive/scope
Test Scope locally in Livepeer mode end to end using a prebuilt go-livepeer artifact from the ja/serverless PR, uv run --extra livepeer livepeer-runner, and Scope.
anthropics/skills
Tests local web applications with Python Playwright scripts, checking frontend behavior, capturing screenshots and reading browser console logs.
microsoft/aspire
A skill your agent uses when asked to trigger or inspect Aspire internal Azure DevOps builds, source-index runs, or release validation on dnceng/internal; push to the internal mirror; download build…
microsoft/aspire
Backports a merged PR to a release branch by triggering the /backport bot, waiting for the bot-created PR, and filling in the shiproom template (Customer Impact, Testing, Risk, Regression?).
microsoft/aspire
Bumps the Aspire repository product version in eng/Versions.props using previous version-bump commits as guidance.
microsoft/aspire
Guide for diagnosing GitHub Actions test failures, extracting failed tests from runs, and creating or updating failing-test issues.
microsoft/aspire
Create a pull request using the repository PR template. An agent skill from microsoft/aspire.
microsoft/aspire
Guide for writing tests for the Aspire Dashboard. An agent skill from microsoft/aspire.
Works with
Categories
A skill your agent uses when creating, modifying, debugging, or reviewing Aspire CLI end-to-end tests that use Hex1b terminal automation under tests/Aspire.Cli.EndToEnd.Tests/. CLI E2E Testing is an agent skill from microsoft/aspire, published by the product's own GitHub organization.Tests/.
CLI E2E Testing fits situations like: reviewing Aspire CLI end-to-end tests that use Hex1b terminal automation under tests/Aspire.Cli.EndToEnd.Tests/; tasks that involve End-to-end testing.
Run `npx skills add microsoft/aspire --skill cli-e2e-testing -a claude-code`. Or copy the skill folder (.agents/skills/cli-e2e-testing in microsoft/aspire) into .claude/skills/cli-e2e-testing in your project. Claude Code loads it when a task matches its description.
Run `npx skills add microsoft/aspire --skill cli-e2e-testing -a codex`. Or copy the skill folder (.agents/skills/cli-e2e-testing in microsoft/aspire) into .agents/skills/cli-e2e-testing in your project. Codex loads it when a task matches its description.
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add microsoft/aspire --skill cli-e2e-testing -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/cli-e2e-testing, .gemini/skills/cli-e2e-testing, .github/skills/cli-e2e-testing and .opencode/skills/cli-e2e-testing in your project.
Going by SKILL.md and its folder, CLI E2E Testing needs the command-line tools its instructions call (dotnet, gh and git) and credentials named GH_TOKEN. Our summary lists: Docker.
SKILL.md contains no URLs. Its commands use gh and git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
CLI E2E Testing is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
About 8.6k tokens (SKILL.md is roughly 34k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
Skills that share tags, products or a category with CLI E2E Testing: E2E Test (crc-org/crc, 1.4k stars), Openclaw Parallels Smoke (SafeAI-Lab-X/ClawKeeper, 1k stars), Cross Platform Gui E2E Test (StudentWeis/ropy, 193 stars) and Build Images (kubernetes-sigs/cloud-provider-azure, 294 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
microsoft (a GitHub organization, an official publisher) maintains it in microsoft/aspire, which has 6,348 GitHub stars. The repository holds 22 skills in this directory. The repository was last updated on October 7, 2026.
Source: microsoft/aspire on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.