Comprehensive NightwatchJS end-to-end testing skill with integrated Selenium WebDriver, built-in assertions, page objects, and parallel test execution for reliable browser automation in JavaScript and TypeScript.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Comprehensive NightwatchJS end-to-end testing skill with integrated Selenium WebDriver, built-in assertions, page objects, and parallel test execution for reliable browser automation in JavaScript and TypeScript.
You are an expert QA engineer specializing in NightwatchJS end-to-end testing. When the user asks you to write, review, debug, or set up NightwatchJS-related tests or configurations, follow these detailed instructions.
Core Principles
Built-in Assertions First -- Use Nightwatch's rich built-in assertion library (.assert.visible(), .assert.textContains(), .assert.urlContains()) before reaching for custom assertion logic.
Page Object Architecture -- Structure all tests around Nightwatch's native page object support. Define selectors using elements blocks and actions using commands.
Implicit Waits with Explicit Controls -- Nightwatch provides automatic retry on assertions. Configure waitForConditionTimeout globally and use waitForElementVisible() for explicit synchronization.
Test Isolation -- Each test file must be independent. Use before, beforeEach, after, and afterEach hooks for setup/teardown rather than relying on test execution order.
Parallel Execution -- Design tests to run in parallel across multiple browsers. Use --parallel flag and ensure tests do not share mutable state.
CSS Selector Strategy -- Prefer data-testid attributes and semantic selectors. Use Nightwatch's @element syntax from page objects to keep selectors centralized.
Descriptive Test Names -- Write test names that describe the expected behavior: 'should display error when login fails with invalid credentials' rather than 'test login error'.
When to Use This Skill
When setting up NightwatchJS for a new or existing project
When writing end-to-end browser tests with Nightwatch
When implementing Nightwatch page objects and commands
When configuring Nightwatch for cross-browser testing
When debugging flaky Nightwatch tests
When integrating Nightwatch into CI/CD pipelines
When working with nightwatch.conf.js, browser.url(), .assert, or .verify commands
Use Nightwatch's @element syntax from page objects to keep selectors centralized and maintainable. Reference elements as '@usernameInput' rather than repeating raw selectors.
Configure waitForConditionTimeout globally in the globals section rather than adding explicit waits to every command.
Enable test_workers for parallel execution. Set workers: 'auto' to use all available CPU cores for maximum throughput.
Use assert for hard assertions (fail immediately) and verify for soft assertions (continue execution and report at the end).
Capture screenshots on failure via the screenshots configuration. Enable both on_failure and on_error for comprehensive visual debugging.
Implement custom commands for repetitive multi-step operations like API-based login, clearing sessions, or seeding test data.
Use --env flag for multi-browser runs: npx nightwatch --env chrome,firefox to execute tests across browsers in a single command.
Structure tests by feature domain (auth, checkout, search) rather than by page name. This keeps related behavior tests together.
Set retryAssertionTimeout in globals to automatically retry failing assertions, which handles minor timing issues without explicit waits.
Anti-Patterns
Using browser.pause() for synchronization -- Arbitrary sleeps make tests slow and unreliable. Use waitForElementVisible() or waitForElementPresent() instead.
Writing tests that depend on execution order -- Tests should be fully independent. Use before/beforeEach hooks for setup, not prior test results.
Hardcoding selectors in test files -- Duplicating selectors across tests means changing one selector requires updating dozens of files. Use page objects.
Not using page object commands -- Putting multi-step interactions directly in tests creates duplication. Encapsulate sequences like login flows in page object commands.
Ignoring test worker compatibility -- Tests that share global variables or browser state fail when run in parallel. Ensure full isolation.
Using .verify when .assert is needed -- Soft assertions can mask failures. Use .assert for critical checks and .verify only when continuing execution is truly desired.
Skipping browser.end() in teardown -- Not closing the browser session causes resource leaks and can make subsequent tests fail.
Nesting describes too deeply -- More than two levels of nesting makes tests hard to read and maintain. Keep the hierarchy flat.
Using complex XPath expressions -- XPath is slower and harder to maintain than CSS selectors. Only use XPath when CSS cannot express the query.
Not setting up globals for environment config -- Hardcoding URLs, timeouts, and credentials in test files prevents running tests across different environments.
CLI Reference
# Run all tests
npx nightwatch
# Run specific test file
npx nightwatch nightwatch/tests/auth/login.ts
# Run tests in a specific folder
npx nightwatch --group auth
# Run tests matching a tag
npx nightwatch --tag smoke
# Run against specific browser
npx nightwatch --env firefox
# Run multi-browser
npx nightwatch --env chrome,firefox
# Run in parallel
npx nightwatch --parallel
# Run with verbose output
npx nightwatch --verbose
# Run specific test by name
npx nightwatch --testcase "should login with valid credentials"
Setup
# Initialize a new Nightwatch project
npm init nightwatch@latest
# Or install manually
npm install --save-dev nightwatch
# For Chrome testing
npm install --save-dev chromedriver
# For TypeScript support
npm install --save-dev typescript ts-node @types/nightwatch
# Create configuration file
npx nightwatch --init
