Setting Up End To End Cross Browser Testing For Your Github Project

Image for post
Image for post

GitHub is widely known as one-stop, where we end up hosting our software development version control using Git. GitHub is extensively used to host a number of projects, be it big or small. However, hosting your website is one thing: getting it live on production and testing it thoroughly to ensure a seamless UI & UX is another. After all, you may have to test your website across hundreds of browsers + OS combinations to ensure you are not missing out to present yourself well for visitors coming on your web application from different browsers. But there is a major challenge when it comes to an end cross-browser testing of your project. TestCafe is one such tool that is designed to work in accordance with the modern Node.js development workflow. It provides extensive features, such as:

  • Use of modern JavaScript in both testing and development of projects with support for ES6 and ES7 features
  • Simple and straightforward installation on your system without any requirement of maintaining additional products and browser plugins
  • Quick integration with CI system
  • The functionality of the tool can be extended with plugins.

I’ll further explain how to set up automation testing for your Node.js GitHub web project using TestCafe. Using a real project as an example, I’ll show how to set up testing in a local browser on your machine, and a step-by-step process to configure continuous integration testing in Travis CI. As mentioned above, the tests are written for Bootstrap, which is a popular JavaScript framework for creating new web projects, and the TestCafe testing framework will be used to execute those tests.

How to write Functional Tests

We will write functional tests for one of the pages of the Bootstrap project that is used to test visual components. To write tests, the page object pattern is used as it enables us to write more affirmative tests. If you want to know more about how to test API, you can review TestCafe documentation.

To write tests, the page object pattern is used as it enables you to write more affirmative tests. If you want to explore more about how to about test API, you can review out TestCafe documentation.

Now let’s start with writing a test for one of the pages in a project with the Modal component of Bootstrap. The Modal dialog consists of various other parts, such as accordion, button, etc.

With the help of the TestCafe selector system, it’s easy to generate a Page Object.I’d further go on to explain the components of the page with its classes in a different page-model.js file. However, if you want to look at the entire page object, then click here.

Page object allows testers to work without the HTML markup while enabling them to operate the object representation of the page. Check out the complete version of the test fixture here.

Start with Testing Local Browser in Development Phase

For testing a modal dialog page, it’s necessary to have an HTTP server for assisting the page. Although testers have their own mechanism of serving tested pages in their project, we are going to use a simple, zero-configuration HTTP server for our project.

To install the TestCafe and HTTP server, we have used the following command:

npm install -g test cafe http-server

As soon as you install the server and TestCafe, you can execute tests in any browser that is installed on your system with one line in the console. Below is the example of executing tests:

test case chrome,firefox js/tests/functional/*-test.js –app “http-server ./ -p 3000”

In the above code, the –app tag enables testers to specify a command that defines the application you want to test. When you launch the TestCafe framework, it will automatically run the http-server, launch the selected browsers, execute tests in them, stop the server, and then provide the test report.

On the other hand, TestCafe CLI is also capable of launching browsers in your system with the path to its executable, deliver arguments to the command that is used for browser launch, and run tests in remote browsers.

Continuous Integration Testing set up.

After browser testing, let’s now focus on setting up continuous integration testing for the GitHub project. For CIT, we will take help from Travis to use it as a CI service. Though it’s viable to use other services as CI, such as AppVeyor or CircleCI, that offer various features, Travis still provides better functionality.

What makes Travis CI unique than others is that it offers a Linux virtual machine that is pre-installed with Firefox and Chrome browser.

First of all, we need to include the modules that were already installed on the project’s dev dependencies. This can be achieved either manually editing the JSON package or using the below command:

npm install test cafe http-server –save-dev

Set up Travis CI for running tests

To configure Travis CI for running tests to each pull request, you will have to enable Travis for your GitHub project. To do so, follow the below steps:

  • Sign in to Travis CI with the GitHub account. If you don’t have an account, then create one.
  • Travis CI will start orchestrating the depositories from GitHub. Once the synchronization is complete, you can check it on your profile page.
  • Now, enable Travis CI for the repository that you want to develop by tapping the switch on.

If you wish to change the pushes and pull request behavior of Travis CI, you can do it in the repository settings.

After changing the behavior of Travis CI, we will configure the .travis.yml.file, which specifies the Node.js version and browser settings. Also, we will set up and use Xvfb for running browsers heedlessly because Travis CI uses virtual machines of the Ubuntu server that doesn’t have a regular graphical environment.

To know more about the Travis configuration, check out the documentation.

Execute Tests for Pull Request in a Pre-Installed Browser

For executing tests in a browser that is already installed to Travis CI, you will have to add an npm test command in the JSON package with the command line that is used for running local tests.

So, when a pull request is generated in the master branch, tests will start running on the Travis CI, and you will be able to view the test run report.

And once they pull request is combined, and modifications are brought to the master branch, Travis CI will execute tests again for the confirmation. Meanwhile, you will be able to see the test status in the Travis CI account.

Configuring Tests for Running in a Headless Browser

If you are not interested in testing browser-dependent behavior for the project, then it will be highly beneficial for you to run tests in a headless browser. It will help you avoid the need to install real browsers on a testing machine, as well as you don’t have to install multiple modules with npm installation, one single module would be enough.

For instance, you could use a plugin for running test cases in NightmareJS, which is designed by the large developer TestCafe community. To install the plugin, use the below code.

npm install testcafe-browser-provider-nightmare –save-dev

After installing the plugin, you can pass a nightmare as a browser name to the test run command.

testcafe nightmare js/tests/functional/*-test.js

Test case enables testers to create their own plugin quickly for any such libraries. To know how to develop plugins with TestCafe, check out this documentation.

Testing your Project on Multiple Browser Using Cross Browser Testing Tools

If you don’t find the above testing process practical or useful, then you can test the project in real browsers with cross-browser testing tools. TestCafe provides an external plugin that enables testers to run tests on virtual machines. You can easily create a free account on these providers and use it for testing your open-source project.

To make things simple, let’s take an example of one of the providers, which is LambdaTest. By using the npm plugin, you can integrate TestCafe with your LambdaTest account. You can go through their documentation for TestCafe Integration With LambdaTest.

Now, let’s start with how you’ll test your project using the TestCafe plugin

First, you need to install the TestCafe plugin with the below command:

npm install testcafe-browser-provider-lambdatest –save-dev

After installing the plugin, specify the login with LambdaTest, and get your access key. To run local tests, you can use the console, but if you want to execute tests on Travis, you will have to specify the credentials in your Travis account.

TestCafe is highly compatible with LambdaTest, which allow it to display all the available browsers for testing with the below command:

testcafe –list-browsers lambdatest

Now, to execute the tests in desktop and mobile browsers, use the following command:

testcafe “lambdatest:Chrome@beta:Windows 10,lambdatest:iPad Simulator@8.1” js/tests/functional/*-test.js –app “http-server ./ -p 3000”

Running this command will allow TestCafe to set up a channel between the machine and LambdaTest Server, run the virtual machines, and then execute the tests to get the desired output.

Also, if you want to open a pull request from a repository fork, then there are a few limitations to it. Travis CI is not capable of performing cross-browser testing in pull requests because it can affect the credentials of LambdaTest that you’re using for testing.


Seeing the above information, you might get an idea that end-to-end cross-browser testing of the GitHub project doesn’t require any delicate operation if you use TestCafe because it is made up of a single console command.

TestCafe can produce results in various formats, such as JSON, spec, minimal, and NUnit while enabling you to create your own report format with a plugin. On the other hand, if you configure TestCafe with the help of a plugin, you can execute the cross-browser testing of your GitHub web project quickly without any fluctuation.

Source: Packaging Solutions

Product Growth at @lambdatesting (

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store