WebdriverIO UI Automation Testing: Build reliable regression with stable locators and controlled data
When one WebdriverIO suite runs across browsers and device capabilities, failures can be hidden behind configuration, element state, or remote logs. The environment must be observable before an assertion is persuasive.
The WebdriverIO UI Testing Skill connects capabilities, user actions, and artifacts so teams can separate product defects from environment-specific failures.
This guide uses reproducible scenarios to show how to apply it: define the risk and evidence first, then organize the checks and results into a defensible next step.
Awesome QA Skills organizes Skills by language and testing stage. The series overview covers repository structure and shared installation options; this guide stays with WebdriverIO UI Testing.
Read the source Skill first
The main prompt covers Quality Bar, Output Format Options, How to Use, Reference Files, Common Pitfalls. Those headings are navigation; the project artifacts still provide the facts.
The source directory contains 1 example files, 2 references, 1 script entries. Start with Test scenario context example, Framework guide, Test execution script.
From artifacts to a runnable entry point
The task is concrete: Automate the checkout journey with WebdriverIO, including stable locators, waits, isolated data, and failure evidence
The input can stay short, but it needs facts.
Journey: sign in → create order → pay → read result
Environment: staging
Available artifacts: interface definition, test account, CI command
Deliverable: test/specs/checkout.e2e.ts, plus the local command and failure evidenceThe Skill should confirm versions, authentication, and data cleanup before generating files. This output fragment demonstrates structure; it does not claim a run occurred.
tool: WebdriverIO
entry: test/specs/checkout.e2e.ts
checks: user-facing locators, isolated data, trace or screenshot evidence
run_evidence: pendingKeep run_evidence pending until a command, report, or trace exists. The source prompt also calls out Quality Bar, Output Format Options, How to Use.
Turn the fragment into a project skeleton
A code fragment becomes useful when its path, command, and artifacts are explicit. Start with one journey.
test/specs/checkout.e2e.ts
├── scenario and assertions
├── data or feeder
├── environment configuration
└── failure artifacts written to artifacts/Use one reproducible local and CI command.
npx wdio run ./wdio.conf.ts --spec test/specs/checkout.e2e.tsKeep capabilities and services in configuration; page objects should expose user actions rather than raw selectors.
Definition of integrated
| Check | Minimum bar | If it fails |
|---|---|---|
| Repeatability | A run does not depend on leftover data | Rework setup and cleanup |
| Diagnosis | WDIO reporter output, screenshots, and service logs identifies the same run | Add a run ID and build ID |
| CI decision | Process exit status matches the quality gate | Fix reporter or threshold configuration |
| Maintenance | Shared authentication and setup have one edit point | Extract a fixture, specification, or user action |
Expand into errors, boundaries, and concurrency only after this journey behaves the same locally and in CI.
A prompt you can adapt
Replace the bracketed fields with project facts. Specific material leaves less room for guessing.
Use the ui-test-webdriverio Skill.
Task: Automate the checkout journey with WebdriverIO, including stable locators, waits, isolated data, and failure evidence
Version and environment: [requirement / build / environment]
Inputs: [file paths or links]
Scope: [included and excluded journeys]
Constraints: [accounts, data, time, compliance]
Check framework version, paths, and authentication first. Generate the smallest runnable entry, command, and artifact list. Mark unexecuted code as not verified.
Finish with open questions. Do not invent missing facts.Use the first pass to inspect structure and gaps. Supply missing material before asking for the handoff-ready artifact.
Advanced use, from one call to a maintained flow
Control the matrix with suites, capabilities, and maxInstances. Archive service logs so browser startup failures are not classified as product defects.
Keep a baseline for duration, pass rate, flaky cases, failure classes, and evidence completeness. Pass rate alone hides too much.
A three-Skill chain
requirements-analysis → ui-test-webdriverio → test-reporting
| Handoff | Payload | Receiver check |
|---|---|---|
| Upstream to ui-test-webdriverio | Source versions, scope, risks, open questions | WebdriverIO UI Testing staleness and conflicts |
| ui-test-webdriverio to downstream | Primary artifact, evidence index, unfinished work | WebdriverIO UI Testing executability and owners |
| Feedback to ui-test-webdriverio | Runs, defects, new risks | WebdriverIO UI Testing baseline and regression update |
Do not paste three complete outputs into one large prompt. Give WebdriverIO UI Testing a structured summary and accessible source artifacts. It saves context and makes defects traceable.
Team gates
| Gate | Check | Failure action |
|---|---|---|
| ui-test-webdriverio input | Version, environment, owner, accessible sources | Stop WebdriverIO UI Testing and list gaps |
| ui-test-webdriverio artifact | Material claims carry basis and status | Return WebdriverIO UI Testing for evidence |
| ui-test-webdriverio execution | Command, exit status, report are reproducible | Classify infrastructure or test failure |
| ui-test-webdriverio decision | Residual risks have accepter and date | Do not enter the next stage |
Review WebdriverIO UI Testing adoption, human edit rate, unsupported claims, and failure-to-diagnosis time each sprint. Record a baseline for several cycles before setting targets.
Common failure modes for this tool family
- Code is generated without a run command, leaving the next person unable to verify it.
- Versions and dependencies are omitted even though WebdriverIO configuration and reporters change.
- Tests share dirty data. API, UI, and performance suites all suffer from leftovers.
- One green run is described as long-term stability. Keep reports, logs, and retry evidence.
Install and invoke
Install the individual Skill. The series overview carries the longer installation explanation.
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/ui-test-webdriverio -g -a codex -yInvoke it with “Use the ui-test-webdriverio Skill,” then attach the real artifacts.
Two practical questions
Will WebdriverIO UI Testing hand me a runnable project?
With complete definitions, versions, paths, and dependencies, it can generate a strong starting point. You still need to install dependencies, run it in your repository, and fix environment differences.
When should generation stop?
Stop when authentication, test data, or the target version is unknown. More generation would only produce a polished guess.
What should be checked first after generation?
Confirm that the entry command discovers the target file and writes failure artifacts to the agreed path. Expand coverage after that works.
Can it enter a release gate immediately?
Wait until local and CI runs use the same command, data resets cleanly, and evidence is traceable.
Run WebdriverIO UI Testing against one real artifact and keep the input, output, and review notes. The fragments here establish structure; project evidence must still come from the project.
References
- Awesome QA Skills project:https://github.com/naodeng/awesome-qa-skills
- Awesome QA Skills series overview:https://inaodeng.com/en/blog/ai-testing/introduction_of_awesome_qa_skills/
- Test scenario context example:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/ui-test-webdriverio/examples/sample-context.md
- WebdriverIO UI Testing (EN) supporting references:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/ui-test-webdriverio/references/framework-spec.md
- WebdriverIO UI Testing (EN) helper script: run-tests.sh:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/ui-test-webdriverio/scripts/run-tests.sh
- Awesome QA Skills: WebdriverIO UI Testing (EN) Skill source:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/ui-test-webdriverio
- WebdriverIO UI Testing Skill details:https://inaodeng.com/en/qaskills/ui-test-webdriverio/