Convert WaitCommandTests to Hex1bTerminalAutomator imperative API#15206
Convert WaitCommandTests to Hex1bTerminalAutomator imperative API#15206mitchdenny merged 2 commits intorelease/13.2from
Conversation
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 15206Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 15206" |
There was a problem hiding this comment.
Pull request overview
This PR converts the Aspire CLI E2E WaitCommandTests from the declarative Hex1bTerminalInputSequenceBuilder approach to the new imperative Hex1bTerminalAutomator API, and adds helper extensions to support common Aspire/Docker terminal flows with improved step-by-step diagnostics.
Changes:
- Add new
Hex1bTerminalAutomatorextension helpers (Aspire prompt detection +aspire newwizard automation). - Add Docker-specific
Hex1bTerminalAutomatorhelpers for environment prep and CLI installation. - Rewrite
WaitCommandTeststo execute steps imperatively via the automator.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| tests/Shared/Hex1bAutomatorTestHelpers.cs | New shared automator extensions for prompt handling, agent init decline, and aspire new interactive flow. |
| tests/Aspire.Cli.EndToEnd.Tests/Helpers/CliE2EAutomatorHelpers.cs | New Docker-focused automator extensions mirroring existing builder helpers. |
| tests/Aspire.Cli.EndToEnd.Tests/WaitCommandTests.cs | Converts the test to the imperative automator API for better failure diagnostics. |
| tests/Aspire.Cli.EndToEnd.Tests/Aspire.Cli.EndToEnd.Tests.csproj | Links the new shared automator helper into the test project build. |
| NuGet.config | Adds a Hex1b GitHub Packages feed + package source mapping (and changes file encoding). |
| Directory.Packages.props | Updates Hex1b package versions to a PR build. |
You can also share your feedback on Copilot code review. Take the survey.
| /// <summary> | ||
| /// Extension methods for <see cref="Hex1bTerminalAutomator"/> providing Docker E2E test helpers. | ||
| /// These parallel the <see cref="Hex1bTerminalInputSequenceBuilder"/>-based methods in <see cref="CliE2ETestHelpers"/>. | ||
| /// </summary> |
NuGet.config
Outdated
| <!-- Begin: Package sources from dotnet-runtime --> | ||
| <!-- End: Package sources from dotnet-runtime --> | ||
| <!--End: Package sources managed by Dependency Flow automation. Do not edit the sources above.--> | ||
| <add key="hex1b-gh-packages" value="https://nuget.pkg.github.com/mitchdenny/index.json" /> |
NuGet.config
Outdated
| @@ -1,4 +1,4 @@ | |||
| <?xml version="1.0" encoding="utf-8"?> | |||
| <?xml version="1.0" encoding="utf-8"?> | |||
Directory.Packages.props
Outdated
| <PackageVersion Include="Hex1b" Version="0.116.0-pr.243.23043055060.555d192.1" /> | ||
| <PackageVersion Include="Hex1b.McpServer" Version="0.116.0-pr.243.23043055060.555d192.1" /> | ||
| <PackageVersion Include="Hex1b.Tool" Version="0.116.0-pr.243.23043055060.555d192.1" /> |
IEvangelist
left a comment
There was a problem hiding this comment.
This is really cool. I do enjoy the fluidity of hex1b (reminds me of writing playwright tests). To that end, when writing playwright tests, I'd often find myself writing helpers just like you've done here - usually though I'd also have a look up class with const values for well-known DOM selectors, classes, or ids. We might want something similar and I think we might be able to use the existing localized strings from the CLI itself. I could be wrong though.
| await auto.DownAsync(); | ||
| await auto.DownAsync(); | ||
| await auto.DownAsync(); | ||
| await auto.DownAsync(); |
There was a problem hiding this comment.
Is there a better (more reliable) way to find options in a selection list? This is essentially hardcoded and fragile, as it will break if the order changes, or more templates are added.
Along those lines, does it make sense to try to use the localized string lookup so that we're not hardcoding those raw values too?
There was a problem hiding this comment.
Good callout! The hardcoded DownAsync() navigation is definitely fragile. A more robust approach would be a helper that knows how to find the top of the list, traverse it looking for the desired item, and detect when the end of the list has been reached — essentially a "search list" abstraction.
For the string matching side, we could use the CLI's resource strings in some places to avoid hardcoding raw text, though that won't cover everything (e.g., list item content that comes from templates rather than localized resources).
The automator API makes these kinds of improvements much easier to approach. They were technically possible before with the sequence builder, but the automator is a more natural fit for building these higher-level helpers. We'll iterate on this as we convert more tests.
Demonstrate the new Hex1bTerminalAutomator imperative testing API by converting WaitCommandTests from the Hex1bTerminalInputSequenceBuilder declarative pattern to the automator's step-by-step async pattern. Changes: - Update NuGet.config: Add hex1b-gh-packages feed for PR packages - Update Directory.Packages.props: Hex1b packages to 0.116.0-pr.243 (from mitchdenny/hex1b#243 which adds the automator API) - Add tests/Shared/Hex1bAutomatorTestHelpers.cs: Automator extension methods (WaitForSuccessPromptAsync, DeclineAgentInitPromptAsync, AspireNewAsync, etc.) with descriptive step names for diagnostics - Add tests/.../Helpers/CliE2EAutomatorHelpers.cs: Docker-specific automator extensions (PrepareDockerEnvironmentAsync, InstallAspireCliInDockerAsync) - Convert WaitCommandTests.cs: Replace builder pattern with imperative automator calls. Each step executes immediately with rich error context on failure (step history, terminal snapshot, caller location). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
1e262f8 to
73d32e1
Compare
|
The transient CI rerun workflow requested reruns for the following jobs after analyzing the failed attempt.
|
🎬 CLI E2E Test RecordingsThe following terminal recordings are available for commit
📹 Recordings uploaded automatically from CI run #23078628589 |
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…5206) * Convert WaitCommandTests to Hex1bTerminalAutomator API Demonstrate the new Hex1bTerminalAutomator imperative testing API by converting WaitCommandTests from the Hex1bTerminalInputSequenceBuilder declarative pattern to the automator's step-by-step async pattern. Changes: - Update NuGet.config: Add hex1b-gh-packages feed for PR packages - Update Directory.Packages.props: Hex1b packages to 0.116.0-pr.243 (from mitchdenny/hex1b#243 which adds the automator API) - Add tests/Shared/Hex1bAutomatorTestHelpers.cs: Automator extension methods (WaitForSuccessPromptAsync, DeclineAgentInitPromptAsync, AspireNewAsync, etc.) with descriptive step names for diagnostics - Add tests/.../Helpers/CliE2EAutomatorHelpers.cs: Docker-specific automator extensions (PrepareDockerEnvironmentAsync, InstallAspireCliInDockerAsync) - Convert WaitCommandTests.cs: Replace builder pattern with imperative automator calls. Each step executes immediately with rich error context on failure (step history, terminal snapshot, caller location). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix unresolved XML doc cref for Hex1bTerminalInputSequenceBuilder Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Mitch Denny <mitch@mitchdeny.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Summary
Demonstrates the new
Hex1bTerminalAutomatorimperative testing API by convertingWaitCommandTestsfrom the declarativeHex1bTerminalInputSequenceBuilderpattern.Motivation
The
Hex1bTerminalInputSequenceBuilder(build-then-apply) pattern makes it difficult to debug failures in long E2E sequences — the exception doesn't pinpoint which step failed. The newHex1bTerminalAutomatorexecutes each step immediately and records a breadcrumb trail. On failure,Hex1bAutomationExceptionincludes:[CallerFilePath]/[CallerLineNumber]Changes
Package Updates
NuGet.config: Addedhex1b-gh-packagesfeed for PR packagesDirectory.Packages.props: Updated Hex1b packages to0.116.0-pr.243(from mitchdenny/hex1b#243)New Files
tests/Shared/Hex1bAutomatorTestHelpers.cs— Automator extension methods:WaitForSuccessPromptAsync,WaitForAnyPromptAsync,WaitForErrorPromptAsyncWaitForSuccessPromptFailFastAsync,DeclineAgentInitPromptAsyncAspireNewAsync(full template wizard automation)success prompt [3 OK] $for diagnosticstests/.../Helpers/CliE2EAutomatorHelpers.cs— Docker-specific extensions:PrepareDockerEnvironmentAsync,InstallAspireCliInDockerAsyncConverted Test
WaitCommandTests.cs— Rewritten from builder pattern to imperative automatorBefore / After
Before (declarative):
After (imperative):
Each
awaitexecutes immediately. If it fails, the exception shows exactly which step, with the full history of what succeeded before it.