A Smattering of Selenium #21

I thought it had been a slow week — until I looked at how many browser windows I had open. I wonder if that was why things were feeling a bit sluggish…

Some bits of history from Simon Stewart

• First announcement of Selenium (outside of Thoughtworks)
• First announcement of WebDriver (again, outside of Thoughtworks)
• The ‘merger’ announcement (aka Selenium 2)

More history lessons on Cloud Computing Show #35 where Jason recounts the origin of Se (and other stuff)

I still maintain that Continuous Deployment to production is near unethical, but a lot of the tricks that companies are using to support it are pretty cool. Continuous Deployment, Code Review and Pre-Tested Commits on Digg4 details some that Digg uses. Only cursory mention of Se, but once you have Se running inside a CI server of some sort, these thoughts become interesting-er.

The Kitchen Sink – why not all tests need automating has things like Just because we can automate a test doesn’t mean that we always should. As a consultant, I need to get this point across to clients all the time. Every. Single. Day.

At the risk of being too meta, there is now Selendion which looks like it drives Concordian with Se

Frank is billing itself as ‘Selenium for iOS’. Except that I believe Se2 already has support for that.

Moving on to the second example is part of a series of posts about exploration of Se2 using Ruby. This particular post is the ruby-fication of the second example of the WebDriver tutorial.

Debugging XPath and CSS locators with Selenium IDE originated with a question on the RobotFramework-Users mailing list and ended up being a screencast. We should do more of those.

Boomerang seems like a project that someone should write a tutorial on integrating with Se

Review: TDD Screencasts is a review of Kent Beck’s new TDD Screencast series (I really should buy this). While yes, we typically don’t do TDD using Se for speed reasons, this paragraph resonated and since I do the list, I’m including it.

A great message I got from the screencasts is that your tests should tell a story. You compose that narrative in steps, so as to not trip yourself up. Many times you are probably required to develop against a backend service or directly with a database. So that’s how the story starts. Hello Mr. Database, are you there? May I put something in you?

If you are a PHP developer and using NetBeans, then Testing with PHPUnit and Selenium might be of interest.

Integrating Selenium Tests into CruiseControl.Net via NUnit is what it claims

Avoiding Brittle Element Selection with Selenium2 tackles a constant topic using Se2 — but it can be applied to Se1 as well