Run Selenium WebDriver UI tests against a Jekyll site on Travis CI
Imagine there is a Jekyll site repository which has some Selenium WebDriver UI tests written with BDD framework Cucumber inside. After each commit, one may find it beneficial to run those tests on Travis CI against this Jekyll site in that particular commit, as part of the continuous integration process.
Instead of running those tests against the live production site each time1, a better way would be to build the site on Travis CI itself, and run the tests against localhost directly.
Implement tests
First of all, there should be some UI tests inside the repository, which can be written using Selenium WebDriver, Watir, or any other suitable automation frameworks, with or without BDD/ATDD frameworks like Cucumber, Capybara, etc. To setup a simple Selenium WebDriver Ruby project on Travis CI, a previous blog article would be useful.
Since the site will be built on Travis CI locally, so the URL will be localhost:4000
instead of the actual live site URL. Bear in mind that port number 4000 can be made configurable if desired.
Install gems
Before building Jekyll and running Selenium UI tests on Travis CI, some necessary gems need to be installed. To do so, within the before_install
section of .travis.yml
file, add in the following commands to install gems, in this case jekyll
, cucumber
and selenium-webdriver
.
Alternatively, adding a Gemfile
inside the repository would also do the job, which should be picked up by Travis Ci automatically.
Start Jekyll web server
To build the Jekyll site locally on Travis CI, add a command to serve Jekyll site with --detach
option in .travis.yml
's before_script
section, which is available since Jekyll 1.2.0 or later. With this --detach
option, web server will be running in background, so that any subsequent commands can be continued and whole Travis CI build won't be hanging.
Run UI tests
In .travis.yml
's script
section, specify the commands to run those cucumber tests.
running tests against production for branches that don't change production is somewhat redundant.
-
Since only the commits in master/gh-pages branches will affect the production site, ↩