Tonight was the May San Francisco Selenium Meetup and since I was in town I put on my combination Selenium-IDE Maintainer and Sauce Labs hat to schmooze.
The main even featured two presentations (Sauce Labs has posted videos); the first by two Mozilla automation folks who talked about their testing rig. Some takeaways…
- They mentioned they use custom firefox profiles for their tests to get around self-signed certificate problems. This is one of my great Se pet peeves. DON’T USE SELF-SIGNED CERTIFICATES IN TEST! Actually, unless you are using certificate based authentication, don’t turn on SSL at all in test. And if you, really, really, really think you need SSL in test (you don’t…) then use a real, issued by a trusted CA certificate. Oh, and custom firefox profiles are a good idea in general anyways as it gives you complete control over the environment (prefs.js is your friend)
- The coolest thing about their whole rig was that it was controlled by a bot you interact with on irc. Outstanding!
- They also created a central module (they use Python) which had all their object locators in it. Not really Element-UI and not really GUI-Map, but it seems to work. Se itself should think about how to support this pattern in a clean, well-documented manner…
- XPath as a pretty deserving reputation for being slow as a locator strategy, but seeing XPath in a script is not a bug. XPath is ridiculously powerful. Bad XPath is a bug, but bad anything is a bug. Good, robust XPath is a good way to access an object.
After Mozilla was Linked-In’s turn to show off their Page Object based testing framework. I also have some notes / opinions on it too.
- Their setup method had @env = Environment.new which is a nice object to be carrying around. I don’t know what was in Environment, but I suspect I’ll be stealing the concept. Or re-stealing I guess as I did something similar 4 or 5 years ago in an old framework but stopped doing it for some reason.
- Using the link locator strategy fails when testing across locales. Duh! Why didn’t I realize that before now?
- The whole framework seemed over-engineered. This was only the send Page Object one I had seen, but that seems to be a pattern. Abstraction is absolutely necessary for success, but to what end?
- What was cool as a result of all this effort was there was no direct Selenium commands in the scripts.
- Jason [Huggins] did some like code review during the talk which provided another key thing to remember when writing scripts and that is to let specific tools do what is better when appropriate. For instance, rather than looping through a list of XPath elements in Selenium (slow), hand off the page source to Beautiful Soup or Nokogiri whose sole purpose of existing is to do that stuff (fast)
One final bit of trivia. The meetup was held at the Mozilla (as in makers of Firefox browser) offices in Mountain View. That same building housed the first offices of Netscape — which of course died a slow painful death and whose source code formed the basis of Firefox. What goes around comes around…