Selenium 2.8 Released
In keeping with our (roughly) weekly releases, Selenium 2.8 was released today (and on Maven too), with a *huge* list of bug-fixes! As well as improved stability, if you’re using the Java API, this release adds the ability to upload files to a RemoteWebDriver server (see RemoteWebDriver.setFileDetector).
Particular thanks have to go out to our two newest committers, Alexei Barancev and Ajay Kemparaj, for the copious bug-fixes they’ve contributed!
We’re already hard at work getting 2.9 ready for next week with even more more bug-fixes – watch this space!
A Smattering of Selenium #63
- Watir to WebDriver: Unit Test Frameworks – Well, its ‘big’ news. Of course, Watir can use WebDriver so they didn’t have to port their scripts to a different API (I sure hope they have the API well abstracted away from their scripts). And of course the title of the post implies that Facebook thinks that Watir/Selenium scripts are ‘Unit’ tests which is suspect at best…
- Selenium tests for Jenkins — Yup; Jenkins now has a set of Se scripts for it. Fork, modify and sent pull requests.
- Thucydides appears to be another full-feature framework built around WebDriver
- NativeDriver and iOS: First Impressions looks to be the first of a series of posts about automating mobile apps
- Managing Locator Builders in Selenium IDE introduces a new feature that we snuck into the most recent version of Se-IDE. Still needs a bit of polish, but we’re getting there.
- The evils of `except:` is a good reminder about naked excepts in your code. Doubly true in automation where you really want to have exceptions bubbling to the top.
- Adding Mozmill tests to the Selenium IDE build system walks you through how to add Mozmill tests to a CI environment. A lot of Se-IDE plugins are really only testable through Mozmill.
- So who is going to buy me a Keep Calm and Continue Testing t-shirt.
- And while we’re at it, who is going to add Se to the Ubuntu Software Center
- This issue’s debate is At Least Three Good Reasons for Testers to Learn to Program vs. At Least 3 Reasons for Software Testers NOT to Learn to Code. Of course, if you are doing Se stuff, that alone is reason to learn to code — automation is programming.
A Smattering of Selenium #62
All opinions, all the time…
- It all began with Test Design for Automation which lead to Automated Test Design (riffing/ripping off Alan Page)
- And then through some weird Jedi mind control there was Design for GUI Automation which in turn led to more UI test design (once more from Alan Page)
- And heck, why have two articles from the same author when you can have three?! It’s (probably) a Design Problem — though I don’t think Chris has riffed off this one yet…
- Remember, Not Every Test Should be Automated!
- Dependency Injection Is NOT The Same As The Dependency Inversion Principle — not that I really understand either really…
- Who knew a collection of scrapebookers is called a ‘crop’? Also, a ‘scrapbooking consultant’? — automation is hard, let’s go scrapbooking! Anyways, Taking on Water is dead on in terms of which things to prioritize when automating.
- Improving the Maintainability of Automated Test Suites by Cem Kaner is an older paper, but the Strategies for Success on page 3 are important. Especially 1, 2 and 5.
- Also from the vaults is Harold’s Corollary to Knuth’s Law which is aimed at Unit not Functional tests, but still is food for thought.
- Why Continuous Deployment Matters
- The Little Black Book on Test Design is meant for exploratory testing, but I bet there is stuff one could pull out of it for automation purposes as well.