Workflow:DevExpress Testcafe Basic Test Authoring
| Knowledge Sources | |
|---|---|
| Domains | Testing, Web_Automation, End_to_End_Testing |
| Last Updated | 2026-02-12 04:00 GMT |
Overview
End-to-end process for authoring a TestCafe browser test from scratch, covering fixture and test definition, element selection, user actions, and assertions.
Description
This workflow describes the standard procedure for writing an automated end-to-end web test using TestCafe. The process starts with creating a test file that declares a fixture (a logical grouping of tests bound to a page URL), then defines one or more test functions containing browser interactions. TestCafe provides a Selector API for targeting DOM elements and a TestController (the t object) that exposes chainable action methods such as click, typeText, pressKey, and dragToElement. Tests conclude with assertions using the built-in expect API that supports smart retries. Optionally, tests can be structured using the Page Object Model pattern for reuse and maintainability.
Usage
Execute this workflow when you need to create a new automated browser test for a web application. You have a target web page URL and a set of user interactions to verify (form submissions, navigation flows, UI state changes). The output is a runnable .js or .ts test file that TestCafe can execute against any supported browser.
Execution Steps
Step 1: Create test file and declare fixture
Create a new JavaScript or TypeScript file (e.g., test.js). Import the Selector API from testcafe if needed. Declare a fixture using the fixture tagged template literal, providing a descriptive name and the target page URL via .page. The fixture groups related tests and sets the starting URL that TestCafe navigates to before each test.
Key considerations:
- Each test file can contain multiple fixtures
- The
.pageURL is navigated to before every test in the fixture - Fixture-level hooks (
.before,.after,.beforeEach,.afterEach) can be chained for setup and teardown
Step 2: Define element selectors
Create Selector instances to target the DOM elements your test will interact with. Selectors accept CSS selector strings or functions and support chaining with filtering methods (.withText, .withAttribute, .nth, .filter) and traversal methods (.find, .parent, .child, .sibling). Selectors are lazy-evaluated and automatically retry until the element appears or a timeout expires.
Key considerations:
- Selectors are re-executable promises that retry on each access
- Use
.withTextand.withAttributefor robust element identification - The
countandexistsproperties enable presence checks - Custom DOM properties and methods can be added to selectors
Step 3: Implement test actions
Define a test function using the test tagged template literal with a descriptive name and an async callback receiving the TestController (t). Chain browser actions on t to simulate user interactions: click, doubleClick, rightClick, typeText, pressKey, selectText, hover, drag, dragToElement, scroll, navigateTo, and others. Actions are automatically awaited when chained.
Key considerations:
- All actions accept a selector or CSS string as the first argument
- Actions wait for the target element to become visible and actionable
- Options objects allow fine-tuning (e.g.,
{ replace: true }for typeText,{ caretPos: N }for click) - Native dialog handling uses
t.setNativeDialogHandler
Step 4: Add assertions
Use the t.expect() API to assert expected outcomes. The expect method accepts a value (often a Selector property like .value, .innerText, .checked) and returns an assertion object with chainable methods: eql, notEql, ok, notOk, contains, notContains, typeOf, gt, gte, lt, lte, within, notWithin, match, notMatch.
Key considerations:
- Assertions on Selector properties use the Smart Assertion Query Mechanism that automatically retries until the condition is met or the assertion timeout expires
- Custom timeout can be set per assertion with the
{ timeout: ms }option - Descriptive messages can be passed as a second argument for debugging
Step 5: Apply Page Object Model (optional)
For larger test suites, encapsulate selectors and reusable interaction patterns into Page Object classes. Create a separate file (e.g., page-model.js) that exports a class with Selector properties. Import and use the page object in test files to improve readability, reduce duplication, and simplify maintenance when the UI changes.
Key considerations:
- Page objects should expose selectors as properties, not raw CSS strings
- Compose page objects from smaller component objects for complex pages
- Keep action logic in tests, not in page objects (page objects are data, not behavior)