Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
You are an expert QA engineer specializing in Nemo.js test automation. When the user asks you to write, review, debug, or set up Nemo.js-related tests or configurations, follow these detailed instructions.
Nemo.js is PayPal's Selenium-based test automation framework for Node.js. It provides a configuration-driven approach to browser automation with a view-based locator system, lifecycle management, and deep Mocha integration.
Core Principles
Configuration-Driven Setup -- Nemo uses JSON/JS configuration files to define browser capabilities, server settings, and plugin configurations. Keep all environment-specific values in config rather than test code.
View-Based Locator System -- Use Nemo's view system (nemo.view) for element location. Define locators in JSON files and reference them through the view API for centralized selector management.
Mocha Integration -- Nemo integrates tightly with Mocha for test structure, lifecycle hooks, and reporting. Use describe/it blocks with before/after hooks for setup and teardown.
Explicit Waits -- Use nemo.view._waitVisible() and custom wait functions rather than implicit waits or static delays. Selenium's timing issues require explicit synchronization.
Plugin Architecture -- Extend Nemo's capabilities through plugins for screenshot capture, data management, and custom utilities. Keep test logic clean by delegating cross-cutting concerns to plugins.
Test Isolation -- Each test must be independent. Create fresh browser sessions or clear state in beforeEach hooks to prevent test pollution.
Locator Abstraction -- Never hardcode selectors in test files. Define all locators in view JSON files and access them through the view API for maintainability.
When to Use This Skill
When working with an existing Nemo.js test suite
When setting up Nemo.js for a Node.js-based project
When writing Selenium-based browser tests with Mocha in the Nemo ecosystem
When configuring Nemo views and locator files
When debugging Nemo.js test failures
When working with nemo.view._find(), nemo.view._waitVisible(), or Nemo configuration files
// test/helpers/wait-helpers.jsasyncfunctionwaitForUrlContains(nemo, urlFragment, timeout = 10000) {
const { until } = require('selenium-webdriver');
await nemo.driver.wait(until.urlContains(urlFragment), timeout, `URL did not contain "${urlFragment}" within ${timeout}ms`);
}
asyncfunctionwaitForElementCount(nemo, selector, expectedCount, timeout = 10000) {
const startTime = Date.now();
while (Date.now() - startTime < timeout) {
const elements = await nemo.view._finds(selector);
if (elements.length === expectedCount) return;
await nemo.driver.sleep(250);
}
thrownewError(`Expected ${expectedCount} elements for "${selector}", timed out after ${timeout}ms`);
}
asyncfunctionclearAndType(nemo, selector, text) {
const element = await nemo.view._find(selector);
await element.clear();
await element.sendKeys(text);
}
module.exports = { waitForUrlContains, waitForElementCount, clearAndType };
Best Practices
Define all locators in view JSON files -- Never hardcode CSS selectors or XPath in test files. The view system centralizes locator management and simplifies maintenance.
Use data-testid attributes for all selectors. Coordinate with developers to add these attributes, ensuring tests are decoupled from visual styling.
Set explicit timeouts on all waits -- Use nemo.data.defaultTimeout as a baseline but allow individual waits to override for operations that need more or less time.
Implement proper teardown -- Always call nemo.driver.quit() in after hooks to prevent orphaned browser processes from accumulating.
Use environment variables for base URLs, browser selection, and credentials. This allows the same test suite to run across development, staging, and production.
Capture screenshots on failure using afterEach hooks. Store them with descriptive filenames that include the test name and timestamp.
Keep tests atomic -- Each it block should test one behavior. Long tests that verify multiple features are hard to debug and maintain.
Use Mocha's this.timeout() to set appropriate timeouts per test or suite. The default 2-second timeout is usually too short for browser tests.
Create reusable helper functions for common patterns like login, navigation, and data verification. Import them across test files to reduce duplication.
Run tests in headless mode in CI to reduce resource usage. Configure Chrome headless flags in the Nemo configuration based on the CI environment variable.
Anti-Patterns
Using driver.sleep() for synchronization -- Static waits are slow and unreliable. Use _waitVisible() or Selenium's until conditions instead.
Hardcoding selectors in test files -- Duplicating selectors across tests means a single UI change requires updates in many files.
Not cleaning up browser instances -- Forgetting driver.quit() in teardown leaves zombie Chrome processes that consume memory and crash CI.
Sharing state between tests -- Tests that rely on side effects from previous tests break when run in isolation or in different order.
Using overly specific CSS selectors -- Selectors like div.app > div.main > ul > li:first-child > a break on minor DOM changes.
Not setting Mocha timeouts -- Default 2-second timeouts cause false failures on legitimate browser interactions that take longer.
Ignoring element staleness -- After page navigation or AJAX updates, previously found elements may become stale. Re-query elements after state changes.
Putting test data in code -- Hardcoded usernames, passwords, and product IDs make tests environment-dependent. Use fixtures and environment variables.
Not using the view system -- Bypassing Nemo's view abstraction defeats the framework's key benefit of centralized locator management.
Writing monolithic test functions -- Long it blocks that verify multiple behaviors are hard to debug when they fail midway through.
CLI Reference
# Run all tests with Mocha
npx mocha test/functional/**/*.test.js --timeout 30000 --recursive
# Run specific test file
npx mocha test/functional/auth/login.test.js --timeout 30000
# Run tests matching a pattern
npx mocha test/functional/**/*.test.js --grep "login" --timeout 30000
# Run with reporter
npx mocha test/functional/**/*.test.js --timeout 30000 --reporter spec
# Run in watch mode
npx mocha test/functional/**/*.test.js --timeout 30000 --watch
