In the days before web applications, programmers wrote applications for a specific platform and used that platform’s native development environment and user interface controls. Before the application’s final release, a tester would check that the application was ready. Some testers wrote elaborate documents that described complicated scenarios they performed on the software manually. Other, more adventurous testers used fancy tools that were the quality assurance version of Microsoft’s Word and Excel macro recorders. A tester would record a series of actions on the software under test. These steps were recorded in a high-level language in which the tester could edit the code and add test conditions that would verify that the actual results of the test matched the expected results. Each time a test was run, a report was generated that showed which conditions had been passed or failed.
With web applications, the time it takes to write and deploy code has been reduced to seconds. In this environment, much of the responsibility for testing is now in the hands of developers, who have since created many code-based test automation platforms.
As good as these tools are, and as widespread as they have become, it isn’t safe to assume that all developers are using them. Developers who aren’t writing test code often use these excuses: they don’t have time, the learning curve is too steep, they’ve tried and it didn’t work, or their management doesn’t care.
However, these excuses aren’t good enough reasons for developers to avoid writing test code. Automated developer tests help detect defects and issues at a much earlier stage in the development process. Automated tests can also be written for a wide range of scenarios. And once a testing suite has been created, it can be reused for existing tests and future scenarios.
Getting started with test automation is easy with the proper tools and frameworks. Automated developer testing is simpler than ever before. All you need to do is pick two frameworks: a test automation framework for writing and running test code, and a browser automation framework for simulating a web browser. This post explains what these frameworks do, examines the most popular options, and discusses the advantages and disadvantages of each respective framework.
Choosing a Test Automation Framework
Most test automation frameworks are based on a common set of agile testing practices. Generally speaking, the development team collects user stories that map to a feature. A user story is a single sentence that states the feature’s persona/role, action, and reason. If you want to enter your user credentials to access the system, each story must have clearly defined acceptance criteria that ensure the implemented feature meets the stakeholder’s/target user’s expectations.
There are a number of competing test runners in use today, but most front end developers use either Jest or Mocha. The good news is that they’re so similar that it doesn’t matter which one you pick.
Below, we have provided a sample Mocha test. The same thing can be written with Jest, and hardly anyone would notice or care. If you’re a React developer and use the create-react-app app builder, the framework automatically generates an initial Jest test for each new project.
Let’s say you’re testing a calculator web application. Start by creating a describe block that will hold one or more tests.
describe('calculator', function () {})Next, add a test using the it function. The test includes a description of what you want to test.
describe('calculator', function () {
it('should show initial display correctly', () => {})
})
Now, add an assertion using the expect function. This assertion checks that the calculator display shows the expected information on launch. The test is only passed if the calculator display shows a zero.
it('should show initial display correctly', () => {
expect(calculator.initialState.display).to.equal('0')
})
In addition to allowing you to write the code, the testing framework lets you run it. To run your test code, type npm test at the command line. When the framework detects changes to your source code, it executes your tests. Each time the framework runs the tests, it indicates if the test was passed or failed.
Comparing Browser Automation Frameworks
A browser automation framework does much more than just simulate a web browser. For starters, these frameworks can launch either full or headless browsers. A headless browser is a browser without a graphical user interface (GUI). Headless browsers are lighter and faster than full browsers, which makes them the ideal tool for automated developer testing.
These frameworks also provide an API that can be used in your test code. This API can simulate users’ browser interactions, capture screenshots, find out the value of input fields, and perform other automation tasks. Unfortunately, choosing a browser automation framework will require a bit more work. Three of the most popular options are presented below.
Selenium Webdriver
If you’re looking for the safest choice, Selenium Webdriver is the way to go. Out of the three framework options we present here, Selenium Webdriver has been around the longest. It’s an open-source project with a very active developer and support community. One of the best things about Selenium Webdriver is that it’s part of the much wider Selenium ecosystem. This provides developer bindings not just for JavaScript, but also for languages such as Java, C#, Python, Ruby, PHP, and Perl.
Over time, Selenium Webdriver has collected a wide range of features, and it’s the only one of the three frameworks presented here that supports all five of the major web browsers (Chrome, IE, Edge, Firefox, and Safari). Selenium Webdriver’s builder API makes it easy to configure and launch the browser instance that you want and set the configuration options that are relevant. It also lets you write code that simulates a wide range of browser user interactions, such as typing text into a text box or pressing a button.
Although Selenium Webdriver has great versatility, features, and integrations, it’s losing popularity since it operates so much slower than its competitors, Puppeteer and Cypress.io.
Puppeteer
One of the newer frameworks is Puppeteer. Puppeteer is excellent for simulating human-like browser interaction. Like Selenium Webdriver, it simulates a wide range of browser user interactions.
Puppeteer also has a range of features that Selenium Webdriver lacks. It can capture screenshots and generate PDFs of specific screens. This makes it a great choice if you want to use it for visual testing. Its speed is also a major benefit for many developers who are choosing a testing tool.
Puppeteer’s other major selling point is that it’s highly integrated with Chrome and its debugging and developer tools. This should come as no surprise since, like Chrome, Puppeteer was developed and is supported by Google. So, if you develop and test your apps only in Chrome, Puppeteer is a great option. However, if you develop with or test against Firefox, Edge, or Safari, Puppeteer won’t work for you and you should go with Selenium Webdriver.
Cypress.io
Cypress.io is a free, open-source front end testing tool. Unlike the two previous frameworks, it’s a complete testing solution. It makes no claims of being a general test automation solution because its main focus is performing end-to-end testing of a web application’s user experience.
Cypress.io’s biggest selling point is its blazing speed. It achieves this speed by running inside the browser. This means that it runs in the same execution loop as your application’s source code (as opposed to Puppeteer and Selenium, which run in a different process than the browser process that renders the application code). This means that Cypress.io doesn’t need to support the control protocols that are required for inter-process communication. This also resolves any system or network latency that slows down sending and receiving commands and responses.
When it comes to discussing any disadvantages of Cypress.io, their documentation is refreshingly open about the product’s benefits and trade-offs. The three most significant cons that may influence your decision relate to the way in which Cypress.io runs tests inside the browser. First, Cypress.io’s method makes it harder to communicate with backend servers, which will mean that you’ll need to install additional modules. Second, it doesn’t support testing multiple browser tabs. Finally, it can only control a single browser instance at a time.
Conclusion: Choose the Right Tool for the Job
When it comes to choosing a test automation framework, you can choose either Jest or Mocha. However, of the browser automation frameworks we looked at, you’ll need to decide between Selenium Webdriver and Puppeteer. If you want a fast, all-in-one solution, Cypress.io is the best choice.
Now that we’ve presented you with the research, all you need to do is pick an option and get started. Once you put the pieces in place and start writing test code, the rest is easy.
To learn more about Applitools’ visual UI testing and application visual management (AVM) solutions, check out the tutorials on the Applitools website. To get started with Applitools, request a demo, or sign up for a free Applitools account.
