SafariDriver: How to run Selenium tests in Safari

Safari is a widely used browser, second only to Google Chrome, with approximately 17.99% global market share as of February 2025. It only makes sense that you can run end-to-end tests for your web applications on it. But to do this, you need SafariDriver, which allows Selenium tests on mobile iOS and macOS.

This article is a loose tutorial featuring the step-by-step process a QA engineer must take to run Selenium tests in Safari using SafariDriver.

Before we get into the details of running Selenium tests on Safari, you should know a few things. Apple stopped supporting its Safari browser on Windows machines. So you’ll need a Mac running the latest version of Safari, which now includes SafariDriver (actually, Safari v10+).

Features of SafariDriver

SafariDriver comes with several built-in features that make it easier to run Selenium tests on Safari. Some of its notable features include:

1. Native Support in Safari – Unlike other browsers that require separate driver downloads, SafariDriver is built into Safari (version 10 and later. This reduces setup complexity.
2. WebDriver Compatibility – SafariDriver is fully compliant with the WebDriver protocol. This allows seamless interaction with Selenium test scripts.
3. Support for macOS and iOS – SafariDriver enables automation on both macOS and iOS devices. This makes it a versatile tool for cross-device testing.
4. Built-in Security Features – When running tests, SafariDriver restricts user input to prevent conflicts between automated actions and manual interactions.
5. Single Test Instance Execution – SafariDriver allows only one test session per browser instance, ensuring controlled execution and avoiding test concurrency issues.

Setting Up Tests With SafariDriver

Step-by-step activation of SafariDriver in Safari browser on a MacBook

To start using your Safari browser for tests, you need to activate the “Develop” menu on the toolbar. To do this, go to Safari >> Preferences >> Advanced. Once you access the options under the Advanced tab, make sure you check the “Show Develop menu …” checkbox. (See screenshot below.)

If done correctly, this is how your toolbar should look:

Then click the “Allow Remote Automation” option. This short drill gets your Mac ready to run Selenium tests without any downloads. This process would be more complex on Chrome and Firefox as their corresponding drivers don’t come installed by default.

A few things to know when running tests:

1. Only one session can run at a time. This prevents the possibility of your tests competing for browser and computing resources. The takeaway is that you can only run a single test instance for each browser instance.
2. Your peripherals will freeze. Once a test is underway, you’ll discover that your keys and mouse cease working. Don’t panic! This is a protection feature activated the instant a test starts. Should you ever need to use either of them, you can pause or completely stop the test by disabling the “Develop” menu (the reverse of our first step) using a command on the terminal: safaridriver –disable

With this knowledge and a Mac environment ready for automated tests, the next step is writing your test and executing it using Safari.

Before we get into this, it may be worth knowing just how your test will be executed:

How your test will be executed

1. Selenium client libraries are the starting point for your test’s interpretation.
2. From there, they are converted into REST API commands.
3. These commands are pushed to the driver (in this case, SafariDriver), which then sends HTTP requests that run the test in your actual browser (Safari running on a Mac).
4. The reverse happens regardless of the test results, and an HTTP response goes the driver’s way. Eventually, you get execution logs with the test’s status.

At this point, we’ll save you the part where you write your code and send you to the SeleniumHQ repository. Where you can get test scripts along with the latest language drivers.

Typically, this entire step should take you anywhere between thirty minutes to an hour, depending on your experience troubleshooting Selenium-related issues. When the test ends, finding out why your application is not working well is a time-consuming task.

It’s no use setting up a rigid workflow that requires further configuration to run cross-browser tests, especially when applications are deployed using CI/CD. The ideal solution is to run the tests isolated from their actual environments.

Troubleshooting and Debugging

While SafariDriver is a reliable tool, you may encounter issues running Selenium tests. Here are common troubleshooting steps:

1. Enable Logging: Run SafariDriver in verbose mode using safaridriver –diagnose to identify issues in test execution.
2. Check Permissions: Ensure Safari has the necessary permissions enabled under System Preferences > Security & Privacy.
3. Clear Cache and Cookies: Corrupt cache data can cause unexpected test failures; clearing them helps resolve session-related issues.
4. Restart the SafariDriver Session: If tests hang or do not execute correctly, restart the session by killing SafariDriver and relaunching it.
5. Debug with Safari Web Inspector: Use Safari’s built-in Web Inspector for analyzing test failures, checking network logs, and reviewing element interactions.

Best Practices for Using SafariDriver

To ensure stable and efficient test execution using SafariDriver, consider these best practices:

1. Keep Safari Updated: Running tests on outdated Safari versions may lead to unexpected failures due to compatibility issues.
2. Use Explicit Waits: Safari’s rendering engine might take time to load elements; prefer explicit waits over implicit ones.
3. Minimize Unnecessary Interactions: Reduce redundant browser interactions in test scripts to optimize test execution time.
4. Run Tests in Isolated Environments: Avoid running multiple Selenium tests simultaneously to prevent session conflicts.

Reduce redundant browser interactions in test scripts to optimize test execution time

Performance Considerations

Running Selenium tests on Safari can be optimized by considering performance factors:

1. Optimize Test Scripts: Avoid excessive element lookups and unnecessary navigation steps to reduce execution time.
2. Limit Animations and Transitions: Disable animations using Safari settings or CSS overrides to ensure stable test execution.
3. Use Parallel Execution Cautiously: Since SafariDriver allows only one session at a time, parallel execution on different devices or VMs may be necessary for scaling.
4. Monitor CPU and Memory Usage: Running multiple tests concurrently can impact system performance; ensure your machine has sufficient resources.
5. Leverage CI/CD Pipelines: Running Safari tests in a CI/CD pipeline can help detect regressions early and automate testing workflows efficiently.

Running Cross-Browser Tests With Testim

You cannot determine which browser your end-user chooses to access your web applications. To counter this uncertainty, you can test your application (at the same time) on the following browsers using Testim:

1. Google Chrome
2. Safari
3. Internet Explorer v11
4. Edge (Chromium too)
5. Firefox

Apart from specifying your browser preference for the test, you only have to specify the OS version on which each of them is running.

Running Automated Tests With CI

We mentioned continuous integration in passing. Don’t let that lead you to think it’s a small topic. Since you’ll need to run multiple tests before deployment, it helps to do things the Testim way. This way, you can integrate Testim with close to ten CI platforms.

These include the following:

1. Circle CI
2. Jenkins
3. Azure
4. GitLab
5. Codeship

Advantages of Running Tests Using Testim

Though we’ve not dived into automated tests using Testim, you should understand the benefits. Often, complexity stops testers (especially developers with no QA experience) from running enough tests. A series of complicated tests can turn into a project of its own. It’s the reason why automated testing is gaining ground over manual methods.

With automated testing methods such as the Testim way, you won’t have to learn how to work with SafariDriver-related technologies. Fast authoring is easy. Just record the scenario and edit it in the visual editor. Then run that test on Safari and other browsers.

With automated testing methods such as the Testim way, you won’t have to learn how to work with SafariDriver-related technologies

Testim uses AI-powered smart locators to identify visual elements. This helps the test find them more easily and more reliably. Selenium is notoriously flaky due to the use of single locators that often change.

Troubleshooting is also easier. You can see side-by-side screenshots showing exactly what happened in the most recent run versus the baseline or last run of the test. If you need more information, the console and network logs are parsed to the test step for additional troubleshooting, so you don’t have to wait for large HAR files.

Finally, Testim helps teams scale their test automation easily with TestOps.

Here’s a bonus. As you know, communication of results is key to getting fast feedback to make changes. This is where Testim shines as compared to Selenium and SafariDriver. Testim uses Slack to share logs and results with developers waiting to deploy new versions.

Start using Testim for free. Only then can you forget about writing test scripts from scratch and the SafariDriver. Focus on making customers happy with fresh versions of the software. After all, customers flock to the company that releases cool features more often than its competitors, even if the other has a complex testing method created from scratch.

What to read next

How to Wait for a Page to Load in Selenium

How to Check If an Element Exists in Selenium