uitest
Automates the creation, execution, and debugging of UI/E2E test plans for the vscode-java-pack using the AutoTest framework.
Install
mkdir -p .claude/skills/uitest && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/14878" && unzip -o skill.zip -d .claude/skills/uitest && rm skill.zipInstalls to .claude/skills/uitest
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Write, update, run, or debug vscode-java-pack UI/E2E tests using AutoTest YAML plans. Use when the user asks for a UI test, E2E test, VS Code UI validation, webview test, Java extension pack workflow test, or autotest plan.Key capabilities
- →Write UI/E2E tests for vscode-java-pack using AutoTest YAML plans
- →Update existing AutoTest YAML plans
- →Validate AutoTest YAML syntax
- →Run tests against a packaged VS Code extension
- →Debug failing E2E tests by inspecting results and screenshots
How it works
The skill uses `@vscjava/vscode-autotest` to execute YAML-based test plans. These plans launch VS Code, install extensions, perform user actions, capture screenshots, and generate test results.
Inputs & outputs
When to use uitest
- →Create a new AutoTest YAML plan for a new VS Code Java feature
- →Update existing test plans in the test-plans directory
- →Validate AutoTest YAML syntax using the CLI
- →Debug failing E2E tests in the vscode-java-pack extension
- →Package the extension for local test execution
About this skill
UI/E2E tests with AutoTest
Use this skill to add or update UI/E2E coverage for vscode-java-pack.
The repository uses @vscjava/vscode-autotest: YAML plans in test-plans/*.yaml launch VS Code, install Java extensions or local VSIX files, execute user-facing actions, capture screenshots, and write test-results/<plan>/results.json.
Prerequisites (local)
- Node.js >= 18 and JDK 21+ installed and on
PATH. - Close any running VS Code instance before running a plan locally; a running instance can block AutoTest from launching its own VS Code.
- When a plan references external sample projects, clone them as siblings of this repo first (CI does this automatically):
git clone --depth 1 https://github.com/redhat-developer/vscode-java.git ../vscode-java
git clone --depth 1 https://github.com/eclipse-jdtls/eclipse.jdt.ls.git ../eclipse.jdt.ls
Workflow
- Identify the scenario and search
test-plans/*.yamlfor an existing plan that already covers the area. - Update the existing plan when possible. Create a new
test-plans/<scenario>.yamlonly when no existing plan fits. - Use stable AutoTest actions and deterministic verifiers. Do not add raw Playwright tests or screenshot-only checks.
- Validate the plan:
npx -y @vscjava/vscode-autotest validate test-plans\<name>.yaml
- If validating the current branch, build and package the extension:
npm ci # first time only; on later iterations run just the two commands below
npm run build
npx @vscode/vsce@latest package -o vscode-java-pack-pr.vsix
- Run the plan against the packaged VSIX:
npx -y @vscjava/vscode-autotest run test-plans\<name>.yaml --vsix vscode-java-pack-pr.vsix --no-llm
- Inspect
test-results/<name>/results.jsonandtest-results/<name>/screenshots/. - Iterate based on the failure cause:
- Incorrect plan: fix the YAML and rerun step 6. No rebuild is needed.
- Product code fix: after editing extension source, re-run step 5 (build + repackage the VSIX) before rerunning step 6. Never rerun against a stale VSIX.
- Product bug (report only): report the observed behavior and cite the failing step, screenshot, and result reason.
Authoring rules
- For most plans, use:
setup:
extension: "redhat.java"
extensions:
- "vscjava.vscode-java-pack"
vscodeVersion: "stable"
- Use
--vsix vscode-java-pack-pr.vsixto test current-branch changes. - Prefer
executeVSCodeCommandorrun commandfor command-driven UI. - Prefer
verifyWebviewfor webview content,verifyTreeItemfor tree views,verifyFilefor generated or modified files,verifyProblemsfor diagnostics, andverifyCompletionfor IntelliSense. - Use
insertLineInFilefor Java source edits that JDT LS must observe. - Use
verifyFileinstead ofverifyEditorafter code actions, organize imports, or rename. - Keep step IDs unique, descriptive, and kebab-case.
- Avoid hard-coded coordinates and brittle DOM structure assumptions.
CI
The repository workflow .github/workflows/e2e-autotest.yml builds a branch VSIX, discovers test-plans/*.yaml, runs plans on Windows/Linux/macOS, and uploads test-results/ artifacts.
Use workflow dispatch when the user asks to validate in CI or across platforms. The test_plan input can target a single plan; leave it empty to run all plans.
When not to use it
- →When adding raw Playwright tests
- →When adding screenshot-only checks
- →When testing current-branch changes against a stale VSIX
Prerequisites
Limitations
- →Requires closing any running VS Code instance before local test execution
- →Does not support raw Playwright tests
- →Does not support screenshot-only checks
How it compares
This skill provides a structured, YAML-based approach for UI/E2E testing of VS Code extensions, ensuring deterministic verification of user-facing workflows, unlike ad-hoc manual testing.
Compared to similar skills
uitest side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| uitest (this skill) | 0 | 1mo | No flags | Intermediate |
| playwright-browser-automation | 29 | 8mo | Review | Intermediate |
| documenso-local-dev-loop | 2 | 1mo | Review | Beginner |
| deepgram-local-dev-loop | 1 | 1mo | Caution | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by microsoft
View all by microsoft →You might also like
playwright-browser-automation
lackeyjb
Complete browser automation with Playwright. Auto-detects dev servers, writes clean test scripts to /tmp. Test pages, fill forms, take screenshots, check responsive design, validate UX, test login flows, check links, automate any browser task. Use when user wants to test websites, automate browser interactions, validate web functionality, or perform any browser-based testing.
documenso-local-dev-loop
jeremylongshore
Set up local development environment and testing workflow for Documenso. Use when configuring dev environment, setting up test workflows, or establishing rapid iteration patterns with Documenso. Trigger with phrases like "documenso local dev", "documenso development", "test documenso locally", "documenso dev environment".
deepgram-local-dev-loop
jeremylongshore
Configure Deepgram local development workflow with testing and iteration. Use when setting up development environment, configuring test fixtures, or establishing rapid iteration patterns for Deepgram integration. Trigger with phrases like "deepgram local dev", "deepgram development setup", "deepgram test environment", "deepgram dev workflow".
customaize-agent:create-hook
LAI-YEN-CHUN
Create and configure git hooks with intelligent project analysis, suggestions, and automated testing
playwright-interactive
ComeOnOliver
Use a persistent `js_repl` Playwright session to debug local web or Electron apps, keep the same handles alive across iterations, and run functional plus visual QA without restarting the whole toolchain unless the process ownership changed.
dependency-upgrade
wshobson
Manage major dependency version upgrades with compatibility analysis, staged rollout, and comprehensive testing. Use when upgrading framework versions, updating major dependencies, or managing breaking changes in libraries.