A Smattering of Selenium #23
I was at Agile 2010 in Orlando last week so missed doing the Smattering, so here is two weeks worth of links.
- There is crazy amounts of power hiding in that there JUnit 4 library – such as @Rule. One usage of them is described here. A useful pattern indeed when doing something like BDD or ATDD
- The next SFSE has been announced; August 24 at LinkedIn. Se creator Jason Huggins will be fielding questions in a Q&A session on steroids.
- While on topic of meetups, Dawn will be presenting about Selenesse at Agile Carolinas also on the 24th
- iCheckWebsite is an accessibility monitoring site which is a niche that I haven’t seen exploited yet. What is interesting is their checklist of what they check for. Looks like a great start for a suite of Se tests.
- Se plays a large part in Continuous Deployment setups, but what I am really interested in is Continuous Delivery. Jez (who literally wrote the book on it) explains the difference between the two.
- One of the better sessions I went to at Agile last week was Mountains to Molehills: A Story of QA that featured some Se content so gets included here.
- Setting up flex testing with selenium – with Selenium Flex API and FlashSelenium
- Selenium 2/Web Driver – the land where Page Objects are king! is the winner of the ‘most twitter love for the last two weeks’ award.
- Samit continues to churn out plugins for Se-IDE, this time with the Log Search Bar Plugin
- The Bromine kids have released a bit of a case study on the Roskilde Festival and CI in Continuous integration of the orange feeling
- Ooo! A completely useless tool competition! – Vote Selenium!
- Web Automation Framework claims to integrate Selenium, TestNG, ReportNG, SimpleXML, Java, Sikuli, Flash-selenium — which is an interesting fruit salad as it lists apples, oranges, bananas and pears when comparing things.
- I hate to pimp my own stuff, but Six Shocking Automation Truths did fairly well from page view perspective. It even spawned a well thought out response/reaction.
- Again, sorry to have my stuff in here, but if you are wondering what Page Objects are (and how to implement them in Python) then my article Page Objects in Python from the August issue of PragPub is what you need.
- Managing Se-Grid machines is a pain (which is why you have companies like Sauce Labs coming into the fray. Another option is to use Copper from GridCentric to have Elastic Build Systems
- One of the Se 2a6 new features was the Web Timings API which David experiments with in Automating the Capture of Web Timings with Selenium 2
- Parallelism is kinda (but not really) solved by Se-Grid, but when you start specing out machines, do you need more threads or cores – and do you know the difference?
- Robot Framework is growing Flash/Flex support; the status of which can be see in this email from the flex-pilot mailing list
Going Atomic: Why?
This is the first in a series of technical posts by me about the internals of Selenium WebDriver. If you’re not interested in technical nitty-gritty, then feel free to step away now.
Still here? Excellent.
Let’s take a step back to just before the Selenium and WebDriver projects merged. There were, very obviously, two separate codebases. Looking closer and with a slightly different perspective, there were more than this. We used the test suites for webdriver to define the behaviour for multiple, largely independent, driver codebases. The IE driver was written in C, the HtmlUnit driver in Java and the Firefox driver is largely Javascript, and so on.
This means that there was a lot of “congruent code”: code that performed the same function but was implemented in a different way. The natural result of this was there was the possibility for behaviour to diverge between drivers. Worse, it meant that when a bug was found, we had to check it in every browser, and it wasn’t certain that an individual could actually fix the code. After all, not everyone is comfortable writing in all the languages we use on the project, or is au fait with all the technologies. For an Open Source project like Selenium, this is a major problem: we rely on a relatively small core of key developers backed up with a far larger team of individuals submitting small changes and fixes. Anything that makes it harder for us to function effectively as a development community is a Bad Thing.
So, we wanted a way off the island; a mechanism that would make it easy to share code between the various drivers and selenium core, that allowed us to fix a bug in one place only and have that fix ripple out to every driver that made use of this mechanism. More importantly, it had to be easy to use, and for someone not familiar with a raft of languages and technologies to quickly get started with.
What would this mechanism look like? Well, there’s a few things that feed into this, but the most important one, was that a majority of the code we’d think of merging was querying the state of the browser (“find an element”, “get the value of this attribute”) and, as Jason Huggins would point out to me at the drop of a hat, the natural language for querying the state of a browser is Javascript. One of the nice things with Javascript is that it’s possible to get a nice, fast development cycle going in it. Just modify a test, save and then hit “refresh” in the browser. That’s kind of attractive. Better still, there are a lot of developers familiar with Javascript.
So, we decided to use Javascript.
Because this shared code was to be composed of the smallest useful fragments of functionality required for browser automation we decided to refer to them as “Browser Automation Atoms”, or “atoms” for short. Rather than write them from scratch, the easiest thing to do was to extract them from the existing code — this is stuff that’s been battle-tested, so we know it’s robust.
There was one very obvious fly in the ointment: not every driver is written in Javascript. Although we have a mechanism available in every browser for executing JS, it’s wildly inefficient to dump an enormous lump of code on to the JS engine of the browser whenever you want to query the DOM. After all, most of the code would not be needed, and not all JS engines have been created equal. Some are blazingly fast. Others, not so much.
It would also be nice to break the code up into manageably-sized modules, rather than being in a single, monolithic file, which implies some clever “module loading” capability. Except this code isn’t always going to be executing inside an environment where writing “script” tags to load additional scripts is possible. You can’t do that in the guts of a firefox extension, though you can load files other ways. However we tie modules together will need to cope with that.
Ah! These opposing requirements: small modules containing the functions we want to use, no extraneous code, and for everything to be in a single file in order to minimize the pain of loading additional modules. That doesn’t sound like a very compatible list. How we resolved those differences is the topic of my next post….
Selenium at Agile 2010
The Selenium project does not have an ‘official’ presence here at Agile as it is seen as a ‘test after’ tool rather than ‘test first’ — even though it provides the magic of the ‘test first’ frameworks… But there is a small, unofficial contingent of recognizable faces around that can help people out and some sessions on it.
Sessions
Why your selenium tests are so dang brittle, and what to do about it – Wednesday, August 11 – 3:30 – 5:00
If you are writing automated through-the-GUI tests for a web application, you are in danger of creating tests that are more expensive to maintain than they are worth. With well-factored Selenium RC tests running in Junit or TestNG, you can keep your abstraction layers or “Lingos” — small bounded bits of slang for discrete parts of the object model — separate, thereby reducing the maintenance costs of your tests, and improving your sanity. Prerequisites include experience with Java or C#, and ideally some *basic* OOD familiarity (inheritance, composition, encapsulation, polymorphism).
Selenium Open Jam – Tuesday, August 10 – 11 – 12
Bring your questions or problems or complaints. We’ll try to ease / solve them.
People
- Dawn Cannan – author of Confessions of a Passionate Tester and maintainer of the .NET version of Selenesse which is a bridge between Selenium and Fitnesse.
- Adam Goucher (me) – maintainer of Selenium IDE and Selenium focused consultant
- Jason Huggins – creator of Selenium and co-founder of Sauce Labs (Selenium in the cloud)
- Patrick Wilson-Welsh – Agile coach and Selenium power user
If you are not succeeding with Selenium, come track down one of us. We might redirect you somewhere else, but eventually we’ll get you sorted out.