Skip to content

v3.5.0
Compare
Choose a tag to compare
@release-drafter release-drafter released this 28 Dec 06:10
· 25 commits to refs/heads/master since this release
v3.5.0
5cef9ac
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

v3.5.0 (2023-12-28)

TestCafe v3.5.0 includes multiple enhancements and bug fixes. Pass Selector queries to the Visual Selector Debugger, explore new ways to specify screenshot path patterns, and use a new experimental flag to run multi-window tests with native automation!

meta-readmore

Pass Selector queries to the Visual Selector Debugger

When you pass a Selector query to the t.debug() method, TestCafe uses the query to populate the input field of the Visual Selector Debugger. The debugger highlights page elements that match the query.

t.debug(Selector('#header'));

Use a custom path pattern for screenshots of failed tests

The pathPatternOnFails screenshot option allows TestCafe users to define a separate set of naming rules for screenshots taken on test failure. You can store these screenshots in a different folder, or add a common, recognizable element to their filenames. You can use this option on its own, or in conjunction with the pathPattern property.

{
    "screenshots": {
        "pathPatternOnFails": "${DATE}_${TIME}/failedTests/test-${TEST_INDEX}/${USERAGENT}/${FILE_INDEX}.png"
    }
}

Specify a path pattern for individual screenshots

Use the pathPattern option of the t.takeScreenshot action to specify a custom naming pattern for an individual screenshot:

t.takeScreenshot({
    pathPattern: "${DATE}_${TIME}/checkout-screenshot.png",
    fullPage: true
})

(Experimental) Run multi-window tests with native automation

TestCafe v2.5.0 was the first version of TestCafe to include native automation --- the capability to automate Chromium-based browsers with the native Chrome Debugging Protocol. This approach offers greater test stability and speed, but has a fair share of limitations. One of them is its incompatibility with multi-window tests.

TestCafe v3.5.0 offers an experimental solution for this issue --- the --experimental-multiple-windows CLI flag. If you enable this flag, you can run multi-window tests with the native automation engine.

The --experimental-multiple-windows mode does not support tests that include the following:

  • Pop-up windows that launch file downloads.
  • Browser window resizing.
  • Screenshots.
  • Video recording.

Please do not use the --experimental-multiple-windows flag in production or for business-critical tasks.

Bug Fixes

  • TypeScript compilation fails if project dependencies include '@babel/plugin-transorm-runtime' v7.23.3 or greater (#8091).
  • If you enable concurrent test execution, TestCafe launches tests before the conclusion of the fixture.before hook (#6999).
  • The Fixture.disableConcurrency method does not disable concurrent test execution (8087).
  • TestCafe ignores the fullPage option when it takes screenshots on test failure (#7761).
  • [Native Automation] TestCafe cannot populate file input fields with the required attribute (#8079).
  • [Native Automation] TestCafe fails to execute tests that use service workers (#8005, #8054).
  • When an action target is obscured by a sticky element, TestCafe incorrectly calculates the scroll distance necessary to interact with the target. (#7377).
  • Incorrect processing of front-end scripts causes automation errors (#7713, #8067, testcafe-hammerhead#2969).
  • TestCafe incorrectly processes failing network requests when it runs on Node.js v16 and greater (#7097).
  • TestCafe incorrectly handles native dialogs in Mozilla Firefox (#6815).
Assets 2