Selenium Setup bores me...

Selenium rocks.  Unfortunately, every time I sit down at a new client I wind up having to do boilerplate setup to get a nose-testable Selenium environment.  By nose-testable I mean something that automatically sets up and closes down the selenium server (and the client servers under test, though that's a separate issue).

To be useful for development, you pretty much need to install FireBug into your profiles, as well as copy over the Selenium auto-inserted extensions (so they don't pop up that annoying "installed add-ons" dialog on every test run).  It's all trivial stuff, but it takes an hour or two to get right (at least), and doing it for every client is a bit of a PITA.

So, since I was sick anyway and couldn't charge for the whole day, I went ahead and took some time off over the past few days to build a little package that contains a Firefox 3.5 profile with the extensions installed (that also works for Firefox 3.0 in my tests so far, though I've only used FF35 for firebug work) as well as some boilerplate code for running the Selenium server in a sub-process with setUp/tearDown friendly code for creating/destroying the whole setup.

Of course, this all assumes that you're running the selenium server on the same machine as the client, but that's okay for me for now.  Eventually I suppose I could have it have an alternate mode where it didn't do that, but at that point you're into wanting to start/stop virtual machines and the like, this is more for "getting started quickly" than having a final solution.

from noseknowsselenium.nns import createSelenium, stopSelenium
class TestFF35(unittest.TestCase ):
def setUp( self ):
self.sel = createSelenium(
browser = '*firefox /usr/bin/firefox-3.5',
def tearDown( self ):
stopSelenium( self.sel )
def test_basic( self ):
title = self.sel.get_title()
assert 'Fletcher' in title, title

with the idea that you'd install NoseKnowsSelenium into your TurboGears virtualenv and then be able to test on a Linux firefox-3.5 desktop.  In the real world you also start your test server in-process and do test setUp/tearDown for that.

Whether to release it is a question.  I doubt there are that many people wanting to use it as-is, and I'll have to keep it up-to-date for new FireBug and Selenium releases (I could likely automate that).  It really feels one of those projects where, were I to release it, someone would just step up and say "oh, that's handled perfectly by this maintained and complete project over here".

So, interwebs, what is the name of that package?


  1. Etienne Desautels

    Etienne Desautels on 07/23/2009 10:13 p.m. #

    Did you tried Windmill instead of Selenium ? It's really nice, works with many browsers AND it's written in python. Maybe it could be easier to setup.

  2. Robert Brewer

    Robert Brewer on 07/24/2009 11:53 a.m. #

    I don't have such a package, but I do find myself in your situation quite a bit. However, I usually don't want to start up selenium once for each test method--that's *far* too slow in my experience. Instead, I usually make a separate SeleniumServer class with "start" and "stop" methods, start it at the beginning of the complete test suite, and stop at the end. I also find parameterizing the set of browsers (instead of hard-coding "*firefox") helps.

  3. Mike C. Fletcher

    Mike C. Fletcher on 07/24/2009 12:26 p.m. #

    Etienne: hadn't heard of windmill before this, will give it a look.

    Robert: I use NoseTest's package-level setup to start selenium and the browser in the real world usage. That is, on entering the functional test suite, a selenium server and client is created, and on exit it is shut down. For the browser code, yup there too, normally in the test config-file for TurboGears. Enjoy.

Comments are closed.


Pingbacks are closed.