Thank you for your interest in TestCafe.
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 include
Isolated 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.
Feel free to ask me about any further technical details.