I'd like to understand more about the decision to not utilize Selenium. The wire protocol used by WebDriver is universally implemented by vendors and a mature piece of software managed by w3c. Why bypass all of this work / functionality?

If TestCafe is not using selenium, how is it driving browser actions? How are selectors, clicks, etc handled? I began digging into the source code, but was quickly overwhelmed by the massive size of the codebase.

I'd love to hear more about the underlying architecture and decisions. It was briefly mentioned that selenium has a few dependencies, but that hardly seems like enough of a reason. Couldn't a fair share of the deps just be auto installed (drivers, etc...). As I understand JDK is only required when running against a remote server, which means it doesn't effect local runs against chrome, firefox, etc...

Awesome to see people solving problems in the space. Grateful of the work, just curious about the decisions.

There are numerous reasons why we decided against building TestCafe on top of Selenium.

First, we wanted to simplify setting up the test environment. To start with Selenium, you need to install the WebDriver client for the desired programming language and the appropriate drivers for each browser you're going to test in.

While it sounds rather easy, practically it's quite a hassle to just get started with testing. This hassle becomes even greater if you need to configure your test environment at scale, e.g. for your local CI server.

There are numerous node.js testing solutions based on top of Selenium in npm. You can see that they require some significant amount of setup and configuration work just to get started. This is far from the simplicity of the npm install setup we got used to in other tools from modern web developer’s tool belt.

TestCafe also has some features that wouldn’t be possible if TestCafe used Selenium as an underlying platform. For instance, TestCafe can run tests on remote devices including mobile. This means that you can run tests on a machine that doesn't have TestCafe installed. You only need to open a link in its browser and the testing starts (if the host and target devices see each other in the network). This feature can be used to quickly demonstrate a bug to an engineer that doesn’t have TestCafe or node.js installed at all.

Other features that would be hard to implement on top of Selenium includeIsolated test environment. Each TestCafe test runs as if it was started in a new incognito tab. You will have all cookies and storages clean. This helps avoid a lot of boilerplate test code and allows you to work in the same browser without the risk of state interference. This also enables us to implement such mechanisms as the upcoming Roles feature with which you’ll be able to interact with the page from different users’ perspective or easily perform form authentication across tests.Implicit auto-waits mechanism. TestCafe automatically waits for XHR requests and page loads, so you don’t need to take care of it in your code.

Finally, as you mentioned, although webdrivers are developed by browser vendors, compatibility issues still appear from time to time.

The main goal of TestCafe is to build a modern functional test harness that will be comfortable to work with. Surely, it would be much simpler for us if we could delegate some parts of the functionality to Selenium while providing the same user experience.

Maybe this will happen someday, but meanwhile TestCafe uses a URL-rewriting proxy under the hood. User actions are emulated via DOM API by a driver script injected by proxy.

This is interesting. The motivation for Selenium 2 WebDriver was to overcome the limitations of Selenium 1 RC, which acted as a proxy server injecting the automation code into the page (which is how TestCafe works, right?). I was able to find that Selenium RC had problems uploading a file, did not handle modal dialogs and there also were problems overcoming browsers single-origin policy. How do you handle these issues?

We've handled all this cases in our proxy. It has full access to the page content, page scripts, http-requests etc. so we can manage it. For example, the proxy opens two ports. One is for requests from the top window to the server, the second is for cross-domain iframes. TestCafe service scripts use window.postMessage to communicate with each other across iframes and overcome single-origin policy.The proxy is tested on tonns of different pages (including pages with different frameworks like React, Vue, Angular etc.) so it works properly in most cases.

Can you please give us a more descriptive introduction to how testcafe and hammerhead are linked and how they communicate sorts of things..? Given the fact there's no much description or documentation for hammerhead online, its hard to get what and how it does.

Testcafe is a great tool btw, love it already. Curious and looking forward to make the most out of it

Hammerhead is our internal tool that is not available to end-users. We created it to separate low-level proxy and resource-injection mechanisms from the automation and user behavior simulation modules. It is closely associated with TestCafe and has a lot of TestCafe-specific features. While Hammerhead can be used as a standalone tool for our own needs, it is not indented for usage by any other third-party projects. Because of this, Hammerhead does not have any documented API. While we may change our mind in the future, we don’t have any plans to ship it publicly and provide any official documentation. If you have any specific questions about Hammerhead, I'll be happy to answer them.

Interesting topic I came across. And thus good find coming across TestCafe tool/solution. Will try someday (not into UI automation as much these days). And as such also don't have much context at the moment into the details of how how it works under the hood beyond the discussion thread here.

But a thought comes across for those who question "why not use Selenium", what if we could do a Selenium/WebDriver wrapper around TestCafe? It could be 3rd party and not part of TestCafe officially. Basically provide WebDriver API to drive TestCafe tests/actions instead of the native scripting provided by TestCafe.

And when it comes to commercial test automation, the makers of Silk are the first that I know of to provide a WebDriver interface to their non-WebDriver-native test automation solution: https://github.com/MicroFocus/SilkAppDriver