Tag: testing

How to install Google Chrome on Travis (in a container-based environment)

Updated 22 Jan 2017: removed the “addons.apt.sources” because looks like the google-chrome source is now provided by default.

Here’s the code. Scroll down for more details:

dist: trusty
sudo: false

addons:
  apt:
    packages:
      - google-chrome-stable

before_script:
  - export DISPLAY=:99.0
  - sh -e /etc/init.d/xvfb start &
  - sleep 3

What’s this#

Travis CI is a popular continuous integration tool. It can be used to run tests when the project code changes, automatically publish changes to the repository, etc., etc. With this config, we configure Travis to install Chrome for each execution. This can be used for e.g. automated UI testing.

Container-based infrastructure#

Since the beginning of November 2016, you can run Ubuntu 14.04 on Travis CI in a container-based environment. A container-based environment is cool because it noticeably speeds up builds, has more resources and more. The drawback is that you can’t use sudo, but Travis has replacements for some common use-cases.

What does this do with Chrome? Chrome can’t be installed on Ubuntu 12.04 which just recently was the only available container-based environment. If you were doing UI testing, you either had to use Firefox (geckodriver) which was buggy as hell or had to accept much longer build times. ¯\_(ツ)_/¯

This config does enable the container-based infrastructure.

What does the code mean#

sudo: false
dist: trusty

sudo: false switches the environment into the container-based mode (and disables sudo). dist: trusty switches the distribution to Ubuntu 14.04 (the default one is 12.04). Here’re the other field values if you need them: https://docs.travis-ci.com/user/ci-environment/

addons:
  apt:
    packages:
      - google-chrome-stable

This installs Chrome. Travis provides the apt addon which is a handy way to install necessary packages. (Also, it’s the only way possible in the container-based infrastructure.)

The packages part of the addon specifies to install the google-chrome-stable package. This package gets installed from the official Google Chrome source which seems to be enabled in Travis by default.

Here’re the docs for the apt addon: https://docs.travis-ci.com/user/installing-dependencies/#Installing-Packages-with-the-APT-Addon

before_script:
  - export DISPLAY=:99.0
  - sh -e /etc/init.d/xvfb start &
  - sleep 3

This starts xvfb (X Virtual Framebuffer) that imitates the display and makes Chrome think it’s run in a GUI environment. sleep: 3 is required to give xvfb time to start (this is what Travis recommends to do). If you need to set the screen resolution or the pixel depth, check out the docs: https://docs.travis-ci.com/user/gui-and-headless-browsers/#Using-xvfb-to-Run-Tests-That-Require-a-GUI

Did this help you? Follow me on Twitter: @iamakulov

UI testing, Selenium, mocking AJAX requests and Likely

Likely are well-designed social buttons:

I’m currently working on covering them with UI tests using Selenium. So far, several notes:

  • Selenium is cross-platform, but different platforms support different sets of functionality. Node.js isn’t the most complete one, unfortunately. If you google how to do something with Selenium, find a StackOverflow reply with the Java API and try to do the same in JavaScript, don’t expect it will definitely work. That API could just be absent.

  • Selenium 3 is coming, but most tutorials focus on Selenium 2. Selenium 2 was released in 2011, and version 3 is expected to be released this year. In fact, the selenium-webdriver npm package already installs 3.0.0-beta.2. There’re no major breaking changes between 2.53.2 and 3.0.0, but expect that some tutorial code could just not work.

  • The selenium docs are scattered between different places, and it’s hard to find the right thing when you’re googling something. One part of the documentation is at docs.seleniumhq.org, another is in the repository wiki, etc. It was quite hard to find the proper actual API docs for JavaScript, so here are they: http://seleniumhq.github.io/selenium/docs/api/javascript/

  • Mock the external services when doing integration tests. When testing the sharing counters, we rely on responses from the social networks. Turns out these services don’t always work well (especially Facebook and Google+) which makes the tests fail. Viktor Karpov suggested to mock the responses, and it seems it’s a default way of doing the integration tests which I didn’t know. I’m working on this now.

  • Mocking AJAX requests with Selenium is hard. I need to mock them to simulate the social network responses (see the previous point). So far, I’ve only found two libraries that can help with this: Sinon.js and xhr-mock. Sinon.js is popular and heavily featured, but it has quite a complex API, and I haven’t yet succeeded in making it work. xhr-mock is way simpler and can also mock only specific URLs (which is more complicated with Sinon), but it doesn’t support XMLHttpRequest.prototype.addEventListener and doesn’t have a UMD build. Sadly.

You can follow the pull request I’m working in to stay tuned (and see how we manage to do the AJAX mocking): https://github.com/ilyabirman/Likely/pull/73