Photo from Chile

Very nice xpath and css selector locator cheat sheet for Selenium

I was recently asked by a colleague for some advice on locators and I shared this cheat sheet with him. It contains just about everything you need to know for formulating locators for use with Selenium (and also Marionette), and includes syntax for both xpath and css selectors.

I hope you find it as useful as I do.

Selenium Locators Cheat Sheet

Please note that I am not the author of the cheat sheet, just someone who finds it very useful.

Debugging Gaia Tests with PyCharm

I've written about PyCharm before. I is my IDE of preference for Python, and I must admit it does an admirable job for html and Javascript as well. I really like its interactive debugging features, which I use all the time when writing and, more often, fixing, Web QA tests. As I have now started working on Gaia (the UI for Firefox OS) tests as well I wanted to try to use Pycharm to interactively debug them as well. I asked my colleague Dave Hunt to help me figure out how to do so during our work week in San Francisco and together we were able to come up with the following solution:

This post assumes you have the gaia-ui-tests project open in PyCharm.


My First Two Months With Mozilla

Yesterday marked my two-month anniversary with Mozilla, and as I never officially announced the start of my employment there (at least not via my blog), I figured it was time to write a post about it.

I realize that this may be news to some readers of this blog, so I'll start with a bit of background. I have been a Mozillian for quite some time, actively contributing to projects primarily for the Web QA department, but also doing a bit for Automation. I have been heavily involved in open source development for several years, and the goal of providing users with more choice through open source software is one that is near and dear to my heart, so taking a job with Mozilla made perfect sense. I am glad to say that it has been everything that I had hoped it would be, and more.

I am now a member of the stupendous Web QA team.

We are responsible for ensuring the quality of Mozilla's many web sites, which include, Mozilla Support, Firefox Add-ons, The Mozilla Developer Network, Firefox Marketplace, and many others. We have also recently been testing Firefox OS, Mozilla's exciting new mobile operating system. My main focus is writing automated tests using Python and Selenium, and more recently Marionette (for Firefox OS), but I have also been using Javascript quite a bit (as that is the basis for Firefox OS).

In addition to that I spend quite a bit of time with Jenkins, which we use for Continuous Integration, and more recently I helped to build an IRC bot using node.js and MongoDB. I plan to write a separate post about that in the near future.

As I mentioned above, it's been a great experience thus far - something I can recommend to anyone. If you're interested in finding out what it's like to be a Mozilla contributor, and having a chance to learn new or improve upon existing skills in testing, Python, Selenium and/or Git, you should check us out. You can find me and my Web QA colleagues in #mozwebqa on, which is really the ideal place to get started. We also have a mailing list that you can join, and you can always find more information about who we are and what we do via our QMO Page. I hope to see some of you online soon!

Getting Started with virtualenv and virtualenvwrapper in Python

There are a couple of tools which can be extremely useful when developing with Python on your local system that I would encourage you to try. These are virtualenv and virtualenvwrapper, and this post will introduce you to them, including instructions for their installation and use.

What is virtualenv?

virtualenv is a tool that allows you to create isolated Python environments, which can be quite helpful when you have different projects with differing requirements. As this is the case with many Mozilla Web QA projects it can be indispensable when working on those.

What is virtualenvwrapper?

virtualenvwrapper is just that, a wrapper utility around virtualenv that makes it even easier to work with. I admit that I have never used virtualenv without virtualenvwrapper, and I do not intend to. For that reason this post will only cover working with virtualenv via virtualenvwrapper. Note also that virtualenvwrapper is a set of shell functions that are guaranteed to work in the following shells:

  • bash
  • ksh
  • zsh

It may run under other shells, and there is a Windows version available called virtualenvwrapper-win


Both virtualenv and virtualenvwrapper can be installed via pip. Install virtualenv first and then virtualenvwrapper. Use the following commands to install them:

view plain print about
1pip install virtualenv
2 pip install virtualenvwrapper


In order to use virtualenvwrapper you should add two lines to your shell startup file (e.g., .bash_profile):

view plain print about
1export WORKON_HOME=$HOME/.virtualenvs
2 source /usr/local/bin/

The first line tells virtualenvwrapper where to store the virtualenvs that will be created and used. The example above stores them in a folder called .virtualenvs inside your home folder. The first line runs the shell script to set up the virtualenvwrapper commands and should point to the location where virtualenvwrapper was installed.

Using virtualenvwrapper to Manage and Work with Virtual Environments

There are a lot of commands available with virtualenvwrapper, all of which are well documented. In my experience, the following are the commands you will use most often:

  • mkvirtualenv - used to create a new virtual environment. When you create a new environment it automatically becomes the active environment.
  • rmvirtualenv - used to remove an existing virtual environment. The environment must be deactivated (see below) before it can be removed.
  • workon - used to activate a virtual environment. Will also list all existing virtual environments if no argument is passed.
  • deactivate - used to deactivate the currently active virtual environment. Note that workon will automatically deactivate the current environment before activating a new one.

Here's an example of how one might use virtualenvwrapper to set up and configure a virtual environment for running tests for a Mozilla Web QA project (marketplace-tests). This code assumes that you already have the Git repo cloned to your local machine and you have navigated to the root folder of the project.

view plain print about
1mkvirtualenv marketplace-tests
2 pip install -Ur requirements.txt

The first line will create and activate a new virtual environment for marketplace-tests, while the second line will install all of the required packages into this virtual environment. Now, whenever you want to work on marketplace-tests you can simply type the command:

view plain print about
1workon marketplace-tests

Using virtualenv and PyCharm

The instructions above are specific to using virtualenv when running Python from the command line. You can also use your virtual environments when running and debugging Python code from within PyCharm. First you have to add your virtual environments to PyCharm's list of Python interpreters:

  1. Open the Preferences (Settings on Windows) dialog and choose Project Interpreter.
  2. Click on the Configure Interpreters link, which will open up the Python Interpreters dialog. Here you will see all of the interpreters currently configured for PyCharm.
  3. Click the + button at the bottom of the list and choose the path to the interpreter in your virtual environment. In my experience sometimes PyCharm is able to find and list these automatically, and other times you have to choose the Local... item and browse for the path yourself. After choosing the path PyCharm will do some setup, displaying a progress indicator and will finally ask you whether you want to set this interpreter as Project Interpreter? Generally you are adding an interpreter precisely because you do want to set it as the interpreter for the current project, in which case you would answer Yes.
  4. Your interpreter will now appear in the list of Python interpreters.

If ever you want to change the interpreter for a given project just access the Project Interpreter dialog again and simply select a different interpreter from the Project Interpreter select list. This option is even available to be changed for individual run configurations, as described in the previous post on Setting Up PyCharm to Run MozWebQA Tests:

  1. Type ctrl + alt + R to open the Run configuration selector.
  2. Type 0, or choose the first option (Edit configurations...) from the select list.
  3. In the Run dialog, beside Interpreter > Python Interpreter, choose your interpreter from the list.
  4. Click Run.

Setting Up PyCharm to Run MozWebQA Tests

PyCharm is a Python IDE, released by JetBrains. I quite enjoy using it and, as I've recently started contributing some tests to Mozilla's Web QA department (mozwebqa), I wanted to use it to interactively debug some mozwebqa tests. This turned out to be a lot trickier than I had imagined, so I am documenting the steps to do so via this post.

This post assumes you have a project open in PyCharm for one of the mozwebqa projects. I am going to use marketplace-tests for this example. As I am on a Mac the instructions and screen shots will be OS X specific, but I imagine they will translate pretty closely to Windows.

Step 1 - Configure py.test as your default test runner

  1. Open up the Preferences... dialog and choose Python Integrated Tools under Project Settings.
  2. Choose py.test as the Default test runner.
  3. Click OK.

Step 2 - Set default run configuration parameters for your project

  1. Type ctrl + alt + R to open the Run configuration selector.
  2. Type 0, or choose the first option (Edit configurations...) from the select list.
  3. In the Run dialog, expand Defaults > Python's test and choose py.test.
  4. Make sure the Python interpreter that you want to use for this project is selected for Python interpreter. If you are using virtualenv you may have to configure a new Python interpreter for your virtualenv. More on that in a separate post.
  5. Choose the root of your project for Working directory.
  6. Click Apply, then Close.

Step 3 - Create a pytest.ini file in the root of your project

This is necessary to pass command line options to py.test. It would be nice if there were a way to do this via the IDE, but I was not able to do it. If anyone knows how, or can figure out how, to do that I'd love to know. I was able to pass a single option to the command line from PyCharm, but could not get it to work with multiple options.

  1. Create a file called pytest.ini in the root of your project.
  2. Add the command line options you need into that file under the [pytest] section. See below for an example from marketplace-tests.
  3. Click OK.
view plain print about
2addopts = --driver=firefox --credentials=mine/credentials.yaml --destructive

Step 4 - Create a copy of credentials.yaml in a personal folder

You are going to have to edit credentials.yaml to place some actual credentials in it, so in order to not have it overwritten each time you do a pull, you should put a copy that you are going to use somewhere else. I tend to create a /mine folder under the project root and place it there, but you can put it anywhere you like. You will notice that the command line option above uses that /mine folder to locate the credentials file.

Step 5 - Run your tests

With a file that contains tests open in an editor window, type ctrl + shift + R and PyCharm will run all of the tests in the file. If you wish to run just one test, type ctrl + alt + R, followed by 0 to open the Edit configurations... dialog and then place the name of your test in the Keywords input. Click Run.

ValidateThis 1.2 - Some Fixes and New processOn Feature

Just a quick note to announce the release of version 1.2 of ValidateThis, an awesome validation framework for ColdFusion. This version includes a new feature: processOn (described below), as well as some small fixes contributed by John Whish and Dustin Martin.


This is a feature that was requested by some users which allows you to define a rule which can be processed on either only the server side or only the client side. You do so by adding the processOn attribute to your rule entity and giving it a value of either server or client. The default value is both, so if you leave this attribute off (as all legacy definitions will) it has no effect and your validations are enforced on both the client and the server.

For those of you still not intimately familiar with the framework, here are some resources to help you out:

  • The main home of the framework is, which includes an online demo and links to all of the following.
  • The framework can be downloaded from the ValidateThis RIAForge page.
  • Online documentation is available at
  • API documentation is available at
  • There is a Google group available for asking questions, making suggestions, and general discussion at
  • The source code is hosted at GitHub, and contributions are always welcome.

CFSelenium 1.8 - Improvements to waitFor Methods and Upgrade for Selenium 2.20

A new version of CFSelenium was released today which upgrades the bundled version of Selenium Server to version 2.20.0, and also includes improvements to the waitFor helper methods. Those improvements were contributed by Michael Wilson.

As always, the latest version is available via the CFSelenium RIAForge page and via the CFSelenium GitHub Project.The latter also includes a detailed Readme file which can help you get started using CFSelenium.

Many thanks to Michael for his contribution.

More Entries