Scouting the TestCafe architecture

From the beginning of time, end-to-end web testing frameworks have depended on external drivers to emulate user actions in real browsers. This approach, however, has a number of downsides:

• Third-party dependencies and a limited number of supported browsers: You had to download, install, configure, and update additional drivers or libraries for each test environment (and sometimes even for each test run). In addition to that, you could only use the browsers supported by each driver.
• Lack of flexibility: Old tools were unable to operate on the tested page directly. As long as the test code does not interfere with the app code, operating on the tested page directly enables the tool to execute many additional scenarios and workarounds. For example, this way it can add and remove styles or change the visibility of any elements on the tested page.
• Code duplication: Legacy testing frameworks ran with the same browser instance during the entire test run, maintaining the tested web application state from test to test (and keeping the same values in cookies and storage). As a consequence, end-to-end tests had a huge amount of duplicated code for clearing the web application state between tests to avoid interference.

However, TestCafe has a fix for each of these problems.

The core idea behind the architecture of TestCafe is that users should not need any external drivers to run end-to-end browser tests. Instead, all the test scripts that emulate user actions can be executed from the page itself. This enables a true cross-platform and cross-browser approach as tests will be able to run on any device with a modern browser!

After each test finishes its execution, TestCafe purges the browser state: it deletes cookies, clears localStorage and sessionStorage, and reloads the page. If you launch several tests in parallel, TestCafe executes each test run in an independent server-side context to prevent server-side collisions.

TestCafe execution can be split into two parts:

• Server-side (in the Node.js process).
• Client-side (in the browser).

Let's take a look at each of these parts.

The server side

Test code is performed in the Node.js environment on the server side. This enables TestCafe to use advantages of standalone server-side code, including the possibility of launching tested web application servers before tests and enhanced control over the testing environment and test execution.

Executing test code in Node.js provides a lot of advantages:

• Database preparation and the launching of the application can be done from within the tests.
• Tests have access to the server's filesystem, so you can read data or create files needed for testing.
• Tests can use all recent syntax features of Node.js. In addition to that, you can include and utilize any Node.js third-party packages.
• Improved stability and speed of execution due to test logic separation from automation scripts.

Since Node.js code executes on the server, it doesn't have direct access to the Document Object Model (DOM) of the page or browser API, but this is handled by custom client-side functions that have access to the DOM and are executed in the browser context.

The client side

TestCafe automation scripts are designed to imitate user actions on any tested page. Their main goal is to enable you to write high-level cross-browser tests, so element-focusing, triggering events, and processing attributes are performed in the same way as a real human would in a browser.

Scripts that emulate user activity (TestCafe internal scripts) run on the client side on the tested page in the browser. This enables TestCafe to utilize the advantages of browser scripts, including built-in smart waits, mobile testing, and user roles. For client-side code to work in the browser, TestCafe proxies the tested page on the server and injects the scripts into its code. This approach is also known as a reverse proxy. When you run TestCafe tests, the browser address bar shows a URL that is prefixed with some digits – this is because TestCafe uses its own open source URL-rewriting proxy (https://github.com/DevExpress/testcafe-hammerhead) and proxies the tested pages.

When you run tests with TestCafe, a reverse proxy is automatically launched locally on your computer. It injects automation scripts into the tested page, so neither the page code nor the resources it communicates with can tell that the page has been modified. In other words, when TestCafe proxies the tested page, it adds automation scripts and rewrites all the URLs on the tested page to point to the proxy:

Figure 2.1 – TestCafe reverse proxies between the user's browser and the web server

When the browser refers to these new, rewritten URLs, the original resources are also proxied and enhanced in the same way. TestCafe also mocks the browser API to separate automation scripts from the rest of the page code. The proxying mechanism is absolutely safe – it guarantees that the page appears to be hosted at the original URL, even to the test code.

In this section, we reviewed how TestCafe operates from the server and client sides. We also learned about the main advantages of this architecture, including the possibility to prelaunch applications before tests, extend control over testing environments, proxying and injecting scripts, which enables smart waiting, mobile testing, and user roles, which we will discuss a bit later.

TestCafe supports JavaScript – the most popular programming language for web development – which allows most users to use their existing coding skills and minimizes the learning curve for newcomers. In addition to that, its clear API makes tests easy to create, read, and maintain. So, let's see what methods TestCafe has to offer.