Want to learn a little more about TestCafé and Nightwatch.js? Christine Zierold compares and contrasts the two UI Test Automation frameworks to help explain the benefits and drawbacks of each.
What is TestCafé?
What is Nightwatch.js?
Both frameworks are installed with one npm command as shown:
However, after executing this command, only TestCafé is immediately functional. As Nightwatch.js connects to a different browser via the Selenium Server, you will also need to install the Java Development Kit (JDK) – minimum version 7 – in order to enable functionality of this framework.
Nightwatch.js is mostly utilized for running on desktop browsers, something that it’s highly noted to do so in other documentation relating to this framework. To leverage the framework for mobile testing, custom configuration of the framework is required alongside Appium, an additional library. The process of enabling this mobile testing can be referenced in this article.
In comparison, due to the usage of the aforementioned proxy instead of the Selenium WebDriver, TestCafé can run on mobile devices by default, without requiring custom configuration.
Using TestCafé requires knowledge of JS, which does not necessarily allow one to quickly switch to or from Selenium WebDriver.
Through my years of experience, I have learned and written code in the following test automation frameworks: Geb & Spock (Groovy), Nightwatch.js (Node.js), Menta (PHP), and Selenium (Java). Each of these is written in a different programming language though all use the Selenium WebDriver. Since they are all Selenium based Automation frameworks, the language is very similar to each other because they all use the WebDriver API and this allows you to transition quickly from one framework to another. The setup and configuration of these frameworks vary, most notably in the time required to complete this initial step. Nevertheless, writing the code itself is similar amongst the frameworks as the WebDriver API is used to communicate with the browser.
While this is a clear advantage when considering transitioning to Nightwatch.js, this should not dissuade you from choosing to write code in TestCafé. This is simply to draw attention to the fact that switching to this framework from Selenium is quite different than switching solely between Selenium WebDriver based automation frameworks. In conclusion, though there may be a learning curve required to fully leverage TestCafé’s functionality, there are numerous and valuable onboard features that make writing code more simple and quick.
‘waitFor’ element to appear, element to be visible, or page to ‘load‘
All Selenium WebDriver based automation frameworks require the test to wait for elements to appear or the page to load, which can prove to be challenging in a QA Engineer’s daily work load to write code for automated tests. The automated test is programmed to click on a button and fill out a designated form. This test can only work if you program the automated test to wait until said form is fully loaded, or until the previously clicked button disappears. These ‘waitFor’ functions are found in most of the code and are required to make the automated test stable including, for example, if a connection to a database takes 10ms longer than normal.
TestCafé does not need these specific ‘waitFor’ functions because it automatically waits for page loads or changes. This changes the whole dynamic and structure of building automated tests. The automated test itself is therefore more stable and solid without requiring the addition of the ‘waitFor’ function.
Nightwatch.js is still a superb framework that QA Engineers should use if staying close to the Selenium WebDriver is important. My first article also discussed the benefits present in this framework. After discovering and working with TestCafé, however, I have come to discover that Selenium is not the sole resource available for writing automated UI testing. TestCafé enables a completely new and exciting dimension in UI test automation and should be leveraged by any QA Engineer who is searching for further efficiencies to be gained in the ongoing writing of automated testing.