How To Perform Cypress Testing Using Webkit?

Tests can be run across multiple browsers with the help of Cypress testing. The Cypress engine currently supports Chrome-family browsers which incorporates browsers like Electron and Chromium-based like Microsoft Edge. WebKit which is Safari’s browser engine, and Firefox are also included in the list. Any browser you wish to run Cypress tests in, excluding Electron, must be installed on your local system or CI environment.

In this blog, we will have a look at how you can perform Cypress testing using WebKit. Before we jump into the intricacies, let us have a look at some of the basics first.

Cypress – what is it?

Cypress is an automated testing framework that runs end-to-end tests quickly and efficiently. It is very much useful to you if you want to automate testing for browser applications. Furthermore, Cypress provides users with tools to observe test results in action out-of-the-box.

A test-driven development framework released in 2017, Cypress is an open-source testing framework. In 2019, Forbes named Cypress a rising star within its authoritative Cloud 100 list based on stories of development teams who have adapted the tool.

As Cypress’ description implies, it can be used to test “anything that runs in a browser”, but it is especially well-suited for front-end developers writing end-to-end tests. With its easy setup, fast performance, and excellent documentation, Cypress makes it easy for anyone with a basic understanding of JavaScript to write tests.

Compared to other testing tools, what makes Cypress different?

Web applications were primarily tested using Selenium for about a decade. Thus, it’s no surprise that Cypress is often compared to its predecessor. Furthermore, the two frameworks utilize completely different architectures, as well as different foci.

The Selenium test runs using a web driver that connects to the browser from the outside. As a result of its modularity, it can be used with various programming languages and browsers such as Python, Ruby, or Scala. As opposed to Cypress tests, which run within the browser, they run alongside the front-end code. Cypress is now at the top of the list in terms of end-to-end test speed because of this.

The flaky test is one of the most dreaded events in software testing. During different runs of a test, a single test produces both failures and passes. Asynchronous browser behavior contributes to flakiness: sometimes, one process must finish before another can succeed. It is possible to circumvent this source of errors in Selenium by adding a ‘wait’ statement. A process’ completion is automatically waited for in Cypress, preventing such cases. It doesn’t completely eliminate the possibility of flaky tests, however. The ‘test retry’ feature in Cypress detects and treats flakiness.

As it stands, Cypress is not here to replace Selenium completely. Due to their different purposes, Selenium and Cypress have very different purposes. While Selenium is more customizable and can be used for many different types of tests, Cypress specifically focuses on E2E testing. With it, you will have a fixed-blade knife to go with Selenium’s multitool.

There are other new kids on the block besides Cypress. There are several new frameworks for testing web sites that specialize in one or more aspects. In many ways, Puppeteer is the same as Cypress, since it’s a JavaScript-based tool. Unlike Cypress, which supports multiple browsers and has an IDE, Puppeteer is a library for the Chrome browser primarily intended for scraping and quick testing web pages.

Is Cypress testing right for you?

If you want to run end-to-end tests rapidly and comfortably using JavaScript (using this add-on, you can use TypeScript as well), Cypress testing is for you. This tool is primarily aimed at front-end developers, for whom testing is only one step of the continuous integration process. Their tests are run and debugged using this tool, so they particularly appreciate it.

However, Cypress’ users are not exclusively developers. If you know a bit of JavaScript, Cypress’ easy setup and steep learning curve make it a great choice. The dashboard and test videos also demonstrate your test’s behavior, just like how a real user would.

WebKit: what is it?

Safari, Mail, App Store, and many other macOS, iOS, and Linux apps use WebKit as their web browser engine. Safari Technology Preview lets web developers test out the latest web technologies, check feature status, report bugs, and follow development.

Cypress and WebKit

Testing in Safari is supported by Cypress. Nearly 20% of internet traffic worldwide comes from Apple’s Safari browser. With 10.8.0, Cypress users can test their web applications with WebKit, the same browser engine as Safari. If your existing Cypress tests are run in WebKit, you can be confident that Safari users will be able to use your web application without any bugs.

How to perform Cypress testing using WebKit?

Version 10.8.0 of Cypress now supports the WebKit browser (Safari). WebKit, the browser engine used by Safari, is supported experimentally by Cypress. You can test how your application would run in Safari by testing it with WebKit.

If we want to execute the test cases in WebKit (Safari), we need to install the latest version of Cypress or upgrade the existing version (if there is an existing version).

Installation Steps

  • Step 1

Cypress’ latest version should be installed or upgraded. The following commands should be run as follows: npm install –save-dev cypress@10.8.0

  • Step 2

Make your configuration experimentalWebKitSupport: true to enable the experiment.

  • Step 3

The playwright-webkit NPM package can be installed in your repo by running npm install –save-dev playwright-webkit.

  • Step 4

When you run the ‘yarn run cypress’ open command, a screen will appear with a list of Test Cases

  • Step 5:

Once you have selected E2E Testing, click on it. A WebKit browser option appears in the new screen. From the screen, select WebKit browser.

  • Step 6

Last but not least, select the test case that you wish to run.

WebKit, the browser engine used by Safari, is supported by platforms such as LambdaTest. Testing your web application with WebKit will give you an idea of how your website or web app will perform in Safari. As of now, LambdaTest supports WebKit on these operating systems:

  • The 11th and 10th versions of Windows
  • Monterey and Big Sur on Mac OS X

Cypress Best Practices

When using Cypress framework, it is essential to incorporate some best practices that will make the testing process more optimal. Have a look below:

  • When selecting elements, use data attributes

Writing selectors that are completely isolated from CSS or JavaScript is one of the best practices when creating E2E tests. In order to prevent your test suite from being broken by CSS or JavaScript updates simply because a selector was changed, you need to create selectors specifically designed for testing.

  • Control State Programmatically

You should always try to set the application’s state programmatically rather than using the UI when you need to run tests under the right conditions. The state will be decoupled from the UI, so you won’t have to worry about it. Using your application’s UI is slower than setting state programmatically, so you will also see a performance improvement.

  • Create a base URL

It is also a good idea to set a base URL globally. Not only can it make your tests cleaner, but it can also make switching between different environments easier, such as from a localhost to a production system.

  • It is important that tests can be passed independently

You can also make this mistake by creating tests that depend on each other. Test cases based on previous tests are brittle and can break if initial conditions are not met, which leads to a brittle test suite.

  • Using cy.wait with a number is not recommended

The cy.wait command can be used with a fixed number which is a common Cypress pitfall. In this case, you are likely waiting for an element to appear or a network request to complete before moving on. Introducing cy.wait ensures that commands have completed before introducing random failures.

Waiting too long is a problem with this method. A network request takes 500 milliseconds to finish, so if you use cy.wait with 5000 milliseconds to wait for it, then you have added 4500 milliseconds to your test suite’s run time.

  • Do not make one assertion at a time

The last but not the least is to avoid using single assertions. For unit testing, single assertions may be useful, but for E2E tests, we need multiple assertions. You will know exactly which assertion failed even if you do not separate them into different test steps.


Using all existing specs in all browsers would be wasteful and not yield much new information. To ensure that Cypress specs are solid, you might want to test them in every browser of interest if you follow our advice to run new and changed Cypress specs multiple times.

When evaluating tools to speed up testing, automation engineers have the same concern. As LambdaTest, a cloud-based automation testing platform, only requires ‘infrastructure changes’ to the source code, this concern can be addressed. You can use LambdaTest’s concurrency calculator to determine the number of parallel sessions needed to obtain the best coverage for a test.

Related Articles

Back to top button