Workflow:DevExpress Testcafe CI Integration

Knowledge Sources	TestCafe TestCafe CI Integration TestCafe Docker
Domains	Testing, CI_CD, DevOps, Web_Automation
Last Updated	2026-02-12 04:00 GMT

Overview

End-to-end process for integrating TestCafe tests into continuous integration pipelines, covering environment setup, headless browser configuration, CI-specific options, artifact collection, and cloud browser integration.

Description

This workflow describes the standard procedure for running TestCafe tests in CI/CD environments such as GitHub Actions, Travis CI, Bitbucket Pipelines, Jenkins, and others. CI environments typically lack a graphical display, requiring headless browser mode or a virtual display (Xvfb). The process covers installing dependencies, configuring browsers for headless execution, setting up reporters for CI-compatible output (xUnit, JSON), collecting screenshots and video artifacts, configuring concurrency for faster runs, and optionally integrating cloud browser providers (SauceLabs, BrowserStack) for cross-browser testing. TestCafe also provides an official Docker image with Chrome and Firefox pre-installed for reproducible CI environments.

Usage

Execute this workflow when you need to run TestCafe tests automatically as part of a CI/CD pipeline triggered by code commits, pull requests, or scheduled builds. You have existing test files and need to configure the CI environment to install TestCafe, run tests in headless browsers, report results in a CI-compatible format, and optionally collect artifacts (screenshots, videos) for debugging failures.

Execution Steps

Step 1: Configure CI environment

Set up the CI job configuration to use a Node.js runtime (version 16+). For Linux-based runners without a display server, either use headless browser modes or install and start Xvfb (X Virtual Framebuffer) with a window manager. Alternatively, use the official TestCafe Docker image (testcafe/testcafe) which includes Chrome and Firefox with a pre-configured virtual display.

Key considerations:

• The Docker image entry point script starts Xvfb automatically via testcafe-docker.sh
• GitHub Actions runners have Chrome and Firefox pre-installed
• Travis CI requires Xvfb and fluxbox window manager for headed mode
• Set the DISPLAY environment variable when using Xvfb

Step 2: Install dependencies

Install project dependencies including TestCafe and any browser provider plugins (e.g., testcafe-browser-provider-saucelabs). Pin versions in package.json to ensure reproducible builds. If using cloud browser providers, configure authentication credentials via environment variables or CI secrets.

Key considerations:

• Use npm ci for deterministic installs from package-lock.json
• Browser provider plugins are auto-discovered by naming convention
• Cloud provider credentials should be stored as CI secrets, not in code
• The connect and serve-static packages can serve local test applications

Step 3: Configure headless browsers

Specify headless browser targets to avoid requiring a display server. Chrome, Firefox, and Edge all support headless mode via the :headless suffix. For cloud browsers, specify the provider and browser combination (e.g., saucelabs:chrome@beta:Windows 10). When running in Docker, the TestCafe image handles display configuration automatically.

Key considerations:

• Headless Chrome: chrome:headless
• Headless Firefox: firefox:headless
• Cloud browsers do not require local browser installation
• The remote browser provider allows external devices to connect to the CI server

Step 4: Configure CI reporters and artifacts

Set up reporters that produce machine-readable output for CI systems. xUnit XML format is widely supported for test result ingestion. Configure screenshot capture on failures and video recording to capture visual evidence for debugging. Store artifacts in CI-designated directories for post-build access.

Key considerations:

• xUnit reporter: --reporter xunit:report.xml
• JSON reporter: --reporter json:report.json
• Screenshots on failure: --screenshots path=artifacts/screenshots,takeOnFails=true
• Video recording: --video artifacts/videos
• Upload artifacts using CI-specific mechanisms (GitHub Actions upload-artifact, etc.)

Step 5: Set execution parameters

Configure CI-appropriate execution options. Enable concurrency to parallelize tests across multiple browser instances for faster feedback. Set stopOnFirstFail if fast failure detection is preferred. Configure appropriate timeouts for CI environments (which may be slower than development machines). Consider quarantine mode for flaky test management.

Key considerations:

• Concurrency: --concurrency N opens N browser instances per target
• Stop on first fail: --stop-on-first-fail
• Adjust selector timeout for slower CI environments
• The exit code equals the number of failed tests (use in CI pass/fail logic)
• Process exits non-zero when tests fail, causing CI to report failure

Step 6: Start application and run tests

If the application under test needs to be started alongside the tests, use the --app flag to specify a startup command and --app-init-delay to wait for the server to be ready. Alternatively, start a static file server or use an already-deployed staging environment URL. Execute the TestCafe command and let the CI system capture the exit code for pass/fail determination.

Key considerations:

• The --app flag starts a child process and waits for appInitDelay milliseconds
• The tested application process is killed after the test run completes
• For already-deployed apps, set the fixture .page URL to the staging environment
• The TestCafe GitHub Action (devexpress/testcafe-action) simplifies GitHub Actions integration

GitHub URL

Workflow Repository