Conversation
02287a2 to
b6822e5
Compare
There was a problem hiding this comment.
Pull request overview
This PR updates the TestCafe runners to attempt to reset UI state before each test by programmatically dispatching a click event on document.body inside the test.before hook.
Changes:
- Dispatch a synthetic
MouseEvent('click')at(0,0)before blurring the active element in the main e2e TestCafe runner. - Apply the same synthetic click in the demos visual-tests TestCafe runner.
Reviewed changes
Copilot reviewed 2 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| e2e/testcafe-devextreme/runner.ts | Adds a synthetic body click in the per-test before hook, alongside existing focus/selection cleanup. |
| apps/demos/utils/visual-tests/testcafe-runner.ts | Adds the same synthetic body click in the per-test before hook for the demos visual-test runner. |
23cc069
| }).with({ boundTestRun: t })(); | ||
|
|
||
| await t.hover('html'); | ||
| await t.hover('html', { offsetX: 1, offsetY: 1 }); |
There was a problem hiding this comment.
The hover offset values (1,1) are magic numbers here. Consider introducing a small named constant (e.g., a MOUSE_RESET_OFFSET) or adding a brief inline comment explaining why these specific offsets are required (e.g., avoiding edge/scrollbar coordinates) to make the intent clearer and avoid accidental changes later.
| window.getSelection()?.removeAllRanges(); | ||
| }).with({ boundTestRun: t })(); | ||
|
|
||
| await t.hover('html', { offsetX: 1, offsetY: 1 }); |
There was a problem hiding this comment.
This introduces a hard-coded hover offset (1,1). To improve readability/maintainability, consider using a named constant for the offset (or add a short comment for why this specific coordinate is chosen) so future changes don’t unintentionally reintroduce cursor-related flakiness.
No description provided.