How to test your application End-to-end
By: Aurélien Lair
Tags: Automation Testing, Nodejs, NPM, Software Engineering, Testcafe

Hello there and welcome back!

This time I want to tell you about something pretty cool we recently introduced in Musement which allows to test your application from a customer’s perspective by using TestCafe.

End-to-end testing in my life:

In all the companies I have worked for, end-to-end testing has always been quite painful and hard to implement especially when dealing with different technological stacks (front-end, back-end, database…). Also because many tools or frameworks claim to be the “best” to help you to solve this problem (have you ever meet the guy below?).

Luckily there are also very nice tools like Selenium. I used it in the past because it met our needs perfectly and is well-suited for PHP (thanks to the little prince contribution on this by the way). In this case we moved forward in a different way thanks to the know-how of our colleague Giorgio who introduced TestCafe as a web-based functional testing framework.

What’s this and how it works?

About the “what” I will not replace Google… the only thing you have to know is that it’s a Node.js tool for automating end-to-end web testing. In a nutshell you need run node and one or more browsers on which you want to run the tests (note that there are also other solutions where you can run tests on remote browsers see “Specify the browsers” in section 2).

1. Installation

By running the above command from the command line you will add the TestCafe package to your package.json packages list. This is the approach I recommend because it allows you to install this package in an instance during the build phase compared to an single installation on a proper computer/server. Let’s not forget that our scope is to allow a perfect continuous integration so we want to optimize the set-up for this.

2.Package json

in the package json file you can specify a list of scripts with an alias. We thought it useful to declare some of them relevant with TestCafe’s run.

httpserver is the alias of the command that launches our application on port 8082. In the chapter “Start app and port listening” you will see how we use it.

e2e is an alias of the command that will start the test suite.

Directories structure

Pages

We divided the tests into “pages” by following the page model pattern (also called page object by Martin Fowler). In the above example you can see that the pages directory contains the login and search pages.

The login page will contain the selectors and the actions of that page:

Fixtures

On the fixture files we write what our expectations are (still from a customer point of view). In this case in order to be able to search we need first to log in, then we can search.

As you can see by separating in pages we can compose different actions on the fixture. Here the login fixture is added to the search one.

Helpers

In the `helpers/index.js` file we put all the functions that are common to the `pages` one in order to avoid duplication (eg. common login + search methods).

Init

this is the most important file because it’s the heart of TestCafe.

In this file we include TestCafe’s framework, we create the test cafe server instance and last by not least we launch the test runner. Like almost all of the functions in TestCafe, all of the runner operations are asynchronous and use promises.

Start app and port listening

First of all we need to specify a shell command that will be executed before running the tests. In this case we want to run our application through the alias we declared in the package json file (and the latest runs an http server with Npm).

Using the reporter

The reporter directive allows you to specify your favourite plugin to output test run reports. In the above example we use one of the plugins offered by the framework but eventually you might want to configure a custom one.

The above example is the details (report) of successful tests while the reports below show the test failures.

Specify the browsers

As mentioned earlier you can specify one or more browsers installed on the computer/server where you are running TestCafe:

As an alternative you can use an external service called BrowserStack to test your application on whatever browser/device you want:

3. Debug mode

One of the nice things with test cafe is you can debug a specific page by opening the browser console when needed.

As you can see in these steps of the login a tool bar appears on the bottom and on the last image you can see that at run time we managed to open Chrome dev tools

Now it’s time to go. I hope you enjoyed this article, guys. Feel free to send me your feedback in the comments section.