Agent skill

Wdio Testing

by ansible in ansible/vscode-ansible

Write, run, and debug WebDriverIO (WDIO) UI tests for the Ansible VS Code extension.

MITAuto-check passedDevOps & Cloud

Install Wdio Testing

skills CLI
$ npx skills add ansible/vscode-ansible --skill wdio-testing -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install ansible/vscode-ansible wdio-testing --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/ansible/vscode-ansible.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.cursor/skills/wdio-testing .claude/skills/wdio-testing && rm -rf skills-src

Use ~/.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/

Facts

Skill name
wdio-testing
GitHub stars
487
Token cost
~2.2k tokens
SKILL.md length
649 words
Files
2
Skills in repo
1
Repo updated
First seen
Licence
MIT

At a glance

Write, run, and debug WebDriverIO (WDIO) UI tests for the Ansible VS Code extension.

  • Works in 2 steps: Open a fixture file to trigger activation → Wait for isActive before proceeding
  • Creating new WDIO specs
  • SKILL.md covers Architecture, Running Tests, Extension Activation (Critical) and executeWorkbench Closure Rules, plus 6 more sections
  • Calls npx

What it does

Wdio Testing is an agent skill from ansible/vscode-ansible. Write, run, and debug WebDriverIO (WDIO) UI tests for the Ansible VS Code extension. Use when creating new WDIO specs, fixing test failures, adding webview or Lightspeed tests, or troubleshooting headless/CI execution.

Its SKILL.md is about 2.2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 1 other file (for example `patterns.md`).

It sits in DevOps & Cloud, covering Infrastructure as code and Failing and flaky tests. It works with Ansible and Visual Studio Code. The repository describes itself as: Ansible IDE extension: auto-completion and integrating quality assurance tools like ansible-lint, ansible syntax check, yamllint, molecule and ansible-test. The licence is MIT.

When your agent uses it

  • Creating new WDIO specs
  • Fixing test failures
  • Lightspeed tests
  • Troubleshooting headless/CI execution

Example prompts

  • “/wdio-testing”

Requirements

  • Node.js

Workflow steps

2 steps, taken from the first numbered list in SKILL.md.

  1. Open a fixture file to trigger activation
  2. Wait for isActive before proceeding

What it can do on your machine

Read from SKILL.md and the folder at commit 98024ea. It shows what the files ask for, not the result of running them.

  • Tool permissions

    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.

  • Runs code

    Shell commands in SKILL.md call:

    • npx

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Links to these hosts (documentation or services it may open):

    • webdriver.io

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Wdio Testing loads about 2.2k tokens when it runs. Until then it costs about 58 tokens; SKILL.md has 649 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~58
When it runs · the whole SKILL.md, loaded when a task matches
~2.2k

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.

Safety

Auto-check passed

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.

SKILL.md

The full file from ansible/vscode-ansible at commit 98024ea, republished under its MIT licence (© ansible). 649 words, ~2,218 tokens.

Download SKILL.mdSave it as .claude/skills/wdio-testing/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
wdio-testing
description
Write, run, and debug WebDriverIO (WDIO) UI tests for the Ansible VS Code extension. Use when creating new WDIO specs, fixing test failures, adding webview or Lightspeed tests, or troubleshooting headless/CI execution.

WDIO UI Testing

Architecture

Each spec file (test/wdio/*.spec.ts) gets its own VS Code Electron instance. The runner is configured in wdio.conf.ts, which uses wdio-vscode-service to download, launch, and drive VS Code via ChromeDriver.

Key paths:

PathPurpose
wdio.conf.tsRunner config: capabilities, extensions dir, user settings
test/wdio/*.spec.tsTest specs (Mocha BDD)
test/wdio/tsconfig.jsonTypeScript config for WDIO tests (CommonJS target)
test/wdio/fixtures/Ansible fixture files opened during tests
test/wdio/mock-server.tsExpress mock for Lightspeed API
scripts/install-test-extensions.mjsInstalls dependency extensions into .wdio-vscode/extensions/
.wdio-vscode/VS Code binary cache + installed extensions (gitignored)

Running Tests

bash
task wdio                   # full suite via Taskfile
npx pnpm test:wdio          # full suite via npm script
TS_NODE_PROJECT=test/wdio/tsconfig.json npx wdio run wdio.conf.ts --spec test/wdio/smoke.spec.ts  # single spec

The TS_NODE_PROJECT env var is required when invoking wdio directly; the Taskfile and npm script set it automatically.

Extension Activation (Critical)

The Ansible extension activates on onLanguage:ansible. In a fresh VS Code session, the extension is not active until an Ansible file is opened.

Every spec that uses extension commands MUST:

  1. Open a fixture file to trigger activation
  2. Wait for isActive before proceeding
typescript
// In the before() hook:
await browser.executeWorkbench(async (vscode, fixture: string) => {
  const folder = vscode.workspace.workspaceFolders?.[0];
  if (!folder) throw new Error("workspace missing");
  const uri = vscode.Uri.joinPath(folder.uri, fixture);
  const doc = await vscode.workspace.openTextDocument(uri);
  await vscode.window.showTextDocument(doc, { preview: false });
}, "playbook.ansible.yml");

await browser.waitUntil(
  async () => {
    const active = await browser.executeWorkbench(async (vscode) => {
      const ext = vscode.extensions.getExtension("redhat.ansible");
      return ext?.isActive === true;
    });
    return active === true;
  },
  { timeout: 60_000, interval: 2000 },
);

See smoke.spec.ts for the canonical waitForExtensionActive() helper.

executeWorkbench Closure Rules

browser.executeWorkbench(callback, ...args) serializes the callback and runs it inside the VS Code extension host process. Outer-scope variables are NOT available inside the callback. This is the single most common source of confusing "X is not defined" errors.

typescript
// BAD -- MOCK_URL is a module-level const; will throw "MOCK_URL is not defined"
const MOCK_URL = "http://localhost:3001";
await browser.executeWorkbench(async (vscode) => {
  const config = vscode.workspace.getConfiguration("ansible");
  await config.update("lightspeed.apiEndpoint", MOCK_URL, vscode.ConfigurationTarget.Global);
});

// GOOD -- pass as an argument after the callback
const url = MOCK_URL;
await browser.executeWorkbench(
  async (vscode, endpoint: string) => {
    const config = vscode.workspace.getConfiguration("ansible");
    await config.update("lightspeed.apiEndpoint", endpoint, vscode.ConfigurationTarget.Global);
  },
  url,
);

Rules:

  • The first parameter is always vscode (the VS Code API).
  • Additional arguments are positional after the callback.
  • Only JSON-serializable values can be passed (no functions, classes, or circular structures).
  • Helper functions defined at module scope (e.g. countTabs(vscode)) are also NOT available inside the callback. Inline the logic or wrap the entire executeWorkbench call in a helper that returns a serializable result.
  • require() is not available in the workbench context. Use the vscode API or run Node utilities from the test runner process directly.

Webview Testing

Webviews render inside nested iframes. After webview.open(), selectors like $("h1") target the webview's DOM. Always call webview.close() when done (use try/finally).

Vue-based webviews render asynchronously. Elements may exist in the DOM but have empty text until the Vue app hydrates. Use waitUntil to poll for rendered content:

typescript
async function waitForWebviewText(
  titlePattern: RegExp,
  textCheck: (text: string) => boolean,
  timeout = 30_000,
): Promise<string> {
  const workbench = await browser.getWorkbench();
  let lastText = "";
  await browser.waitUntil(
    async () => {
      try {
        const webview = await workbench.getWebviewByTitle(titlePattern);
        await webview.open();
        const body = await $("body");
        if (await body.isExisting()) lastText = await body.getText();
        await webview.close();
        return textCheck(lastText);
      } catch { return false; }
    },
    { timeout, interval: 2000 },
  );
  return lastText;
}

Open webview commands via executeWorkbench (not workbench.executeCommand) to avoid command palette timing issues:

typescript
await browser.executeWorkbench(
  async (vscode, cmd: string) => {
    await vscode.commands.executeCommand(cmd);
  },
  "ansible.content-creator.menu",
);

Mock Server for Lightspeed

test/wdio/mock-server.ts is a standalone Express server with canned responses for Lightspeed API endpoints.

Usage in a spec:

typescript
import * as mockServer from "./mock-server";

before(async () => {
  await mockServer.start(3001);
  // point the extension at the mock
  await browser.executeWorkbench(
    async (vscode, endpoint: string) => { /* update setting */ },
    "http://localhost:3001",
  );
  await injectMockSession();
});

after(async () => {
  // restore original setting, then stop
  await mockServer.stop();
});
  • mockServer.setResponse(endpoint, status, body, delay?) -- override a specific endpoint per test.
  • mockServer.resetResponses() -- revert to defaults (call in afterEach).
  • injectMockSession() -- calls the ansible.lightspeed.mockSession command to fake an authenticated user. Uses waitUntil because the command is only available after the extension finishes activating.
Show full SKILL.md (243 more words)Show less

Adding Dependency Extensions

If the extension under test gains new extensionDependencies, add them to the DEPENDENCY_EXTENSIONS array in scripts/install-test-extensions.mjs:

javascript
const DEPENDENCY_EXTENSIONS = [
  "ms-python.python",
  "ms-python.vscode-python-envs",
  "redhat.vscode-yaml",
  // add new entries here
];

Run npx pnpm pretest:wdio to install them into .wdio-vscode/extensions/.

CI and Headless Execution

Linux CI (GitHub Actions)

The Taskfile wraps the test command with xvfb-run on Linux:

yaml
cmds:
  - "{{.XVFB}}npx pnpm test:wdio"

XVFB is set to xvfb-run --auto-servernum when Xvfb is available.

--disable-gpu

Always set in wdio.conf.ts under vscodeArgs. Prevents GPU-related crashes in headless environments. Safe on all platforms.

Do NOT use --no-sandbox

This flag causes SIGSEGV crashes on many Linux systems (Fedora, newer kernels). Electron's sandbox is required for stable operation under Xvfb.

Wayland vs X11

On Wayland desktops, the VS Code window will be visible during local test runs. This is expected; xvfb-run on CI handles headless. Do NOT set WAYLAND_DISPLAY="" as it can trigger Xvfb/Electron crashes.

Common Pitfalls

PitfallCauseFix
"X is not defined" inside executeWorkbenchClosure variable capturedPass as argument (see above)
Extension commands not foundExtension not activatedOpen fixture + waitUntil(isActive)
getCommands() misses some commandsregisterTextEditorCommand isn't listedUse getCommands() without true filter, or just execute the command and catch errors
Notification check throws.monaco-list-row not displayedWrap getNotifications() in try/catch
Webview text is emptyVue hasn't rendered yetUse waitUntil to poll for text content
SIGSEGV under Xvfb--no-sandbox flagRemove it; keep only --disable-gpu
workbench.executeCommand timeoutCommand palette focus raceUse executeWorkbench + vscode.commands.executeCommand instead

Additional Resources

© ansible, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file in .cursor/skills/wdio-testing of ansible/vscode-ansible.

  • SKILL.md
  • patterns.md

Open the folder on GitHubat commit 98024ea

Compare with similar skills

Wdio 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.

Wdio Testing compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Wdio Testing this skillansible/vscode-ansible487—~2.2kAutomated safety check: PassMIT
Azure Pipelines Log Downloaderansible/ansible71k—~825Automated safety check: PassGPL-3.0
Spa Create Configsplunk/splunk-platform-automator137—~3.5kAutomated safety check: PassProprietary
Spa Add Test Scenariosplunk/splunk-platform-automator137—~2.2kAutomated safety check: PassProprietary
Frontend Overlayansible/ansible-ui113—~2.5kAutomated safety check: NotesApache-2.0
Run Testsansible-collections/ansible.mysql134—~1.2kAutomated safety check: PassCustom licence

Similar skills

  • Downloads Azure Pipelines CI logs for an Ansible pull request or build so the agent can analyze test failures, after asking you first.

    71k GitHub stars~825 tokensUpdated yesterday
    DevOps & CloudAuto-check passed
  • Spa Create Config

    splunk/splunk-platform-automator

    A skill your agent uses when creating or updating splunkconfig.yml, designing Splunk Enterprise lab topology, multisite IDXC, SHC layout, architecture plan before config, or AWS Terraform block for…

    137 GitHub stars~3.5k tokensUpdated 2 days ago
    DevOps & CloudAuto-check passed
  • Spa Add Test Scenario

    splunk/splunk-platform-automator

    A skill your agent uses when adding app scope/routing test coverage (deployer, CM, DS, direct).

    137 GitHub stars~2.2k tokensUpdated 2 days ago
    DevOps & CloudAuto-check passed
  • Frontend Overlay

    ansible/ansible-ui

    Product-specific frontend wrappers, API clients, and paths for ansible-ui.

    113 GitHub stars~2.5k tokensUpdated today
    DevOps & CloudAuto-check: notes
  • Run Tests

    ansible-collections/ansible.mysql

    Runs and writes tests (sanity, unit, integration) for the ansible.mysql Ansible collection using ansible-test.

    134 GitHub stars~1.2k tokensUpdated 2 days ago
    DevOps & CloudAuto-check passed
  • Run Tests

    ansible-collections/community.postgresql

    Runs and writes tests (sanity, unit, integration) for the community.postgresql Ansible collection using ansible-test.

    144 GitHub stars~1k tokensUpdated 15 days ago
    DevOps & CloudAuto-check passed

Categories

Questions about Wdio Testing

What does Wdio Testing do?

Write, run, and debug WebDriverIO (WDIO) UI tests for the Ansible VS Code extension. Wdio Testing is an agent skill from ansible/vscode-ansible. Write, run, and debug WebDriverIO (WDIO) UI tests for the Ansible VS Code extension.

When should I use Wdio Testing?

Wdio Testing fits situations like: creating new WDIO specs; fixing test failures; lightspeed tests; troubleshooting headless/CI execution.

How do I install Wdio Testing in Claude Code?

Run `npx skills add ansible/vscode-ansible --skill wdio-testing -a claude-code`. Or copy the skill folder (.cursor/skills/wdio-testing in ansible/vscode-ansible) into .claude/skills/wdio-testing in your project. Claude Code loads it when a task matches its description.

How do I install Wdio Testing in Codex?

Run `npx skills add ansible/vscode-ansible --skill wdio-testing -a codex`. Or copy the skill folder (.cursor/skills/wdio-testing in ansible/vscode-ansible) into .agents/skills/wdio-testing in your project. Codex loads it when a task matches its description.

Can I use Wdio Testing in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add ansible/vscode-ansible --skill wdio-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/wdio-testing, .gemini/skills/wdio-testing, .github/skills/wdio-testing and .opencode/skills/wdio-testing in your project.

What does Wdio Testing need to run?

Going by SKILL.md and its folder, Wdio Testing needs the command-line tools its instructions call (npx). Our summary lists: Node.js.

Does Wdio Testing access the network?

SKILL.md names 1 domain. As links in the text: webdriver.io. This is read from the text; nothing was executed.

Is Wdio Testing safe to install?

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.

What licence does Wdio Testing use?

Wdio Testing is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Wdio Testing use?

About 2.2k tokens (SKILL.md is roughly 8.9k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Wdio Testing?

Skills that share tags, products or a category with Wdio Testing: Azure Pipelines Log Downloader (ansible/ansible, 71k stars), Spa Create Config (splunk/splunk-platform-automator, 137 stars), Spa Add Test Scenario (splunk/splunk-platform-automator, 137 stars) and Frontend Overlay (ansible/ansible-ui, 113 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Wdio Testing?

ansible (a GitHub organization) maintains it in ansible/vscode-ansible, which has 487 GitHub stars. The repository was last updated on October 7, 2026.

Source: ansible/vscode-ansible on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.