With the new year and the subsequent budget resets I am seeing a bunch of inquiries along the lines of ‘We want to [use build] a Selenium record-playback tool’ which I am more vigilantly responding with a variant of ‘No, you really don’t’. This post is the longer version of ‘No, you really don’t’.

Maybe you do want to Record-Playback

First, the ‘Yes, you really do.’ If you are looking at a/for a tool that will

  • Do quick bug capture for attaching to to a bug report
  • Do quick session establishment to enable exploratory testing
  • Capture short-lived, throwaway script

then sure, fire up a record-playback tool and have at it. But most people making the inquiries want to do what I label ‘full bore automation’ and record-playback falls flat on its face in that situation. And here is why.

Early intermission

I was the maintainer of Se-IDE for about two years eventually giving it up since the irony of me working to make something better only to suggest to people they should pretend that the tool doesn’t exist. I also fully credit Se-IDE as the primary reason why ‘we’ ‘won’ the browser automation game. [Or at least this round.] I am now in the role of ‘minister without portfolio’ in the Se project and was the loudest voice in dissent against including Se-Builder into the project. It got accepted anyways and will eventually replace Se-IDE as the ‘official’ record-playback tool for Se. It addresses some of the code/maintainability problems that Se-IDE suffers from, but it still does not address the following problems inherit with the category of tools. Nor does anything else on the market that I have seen.

Maintainability

The best idea we have come up with to ease the maintenance burden of when something changes is Page Objects. And if you do POs ‘properly’ you will end up with a highly custom hierarchy of classes that work in your specific context. It is impossible for the tool to know and understand that hierarchy and and accurately predict where to insert new code which means you will be doing a tonne of manual code movement after the record.

Before POs came onto the scene, updating scripts involved lots of find/replace/grep/awk/sed magic. Some of which can be hidden away through the use of an external locator strategy like WinRunner’s GUI-Map stuff, but has its own problems. (And a solution like that doesn’t exist is most tools these days; certainly not the Se ones at any rate.)

Toolchain Integration

As we move towards more modern development cycles we need to be able to run our scripts from anywhere. That wonderful Windows UI doesn’t work on the Linux build infrastructure. Nor does tightly coupling with Eclipse. Some vendors provide the ability to run the scripts external to their tool which is kinda a cheat when you market a ‘record playback solution’. Se’s record-playback solutions are lacking this officially, though there are a number of half-complete projects that do this.

Remember, in the grand scheme, your machine does not matter if something passed or failed.

Lack of a Brain

For years the slag on Se-IDE was that its locators were ‘brittle’ — which they were, even though they were technically correct. Humans can catch when something is brittle and adjust it — possibly by using a different subset of the standard or breaking it up into parts or whatever. Unless mated to a positronic brain or such, no tool is going to be able to make that leap.

Explicit vs. Implicit

No, this is not in reference to Waits (though yes, you want to use explicit waits rather than implicit ones). When you treat automation as a programming exercise, every bit of code that is there, you put there. Its not magic inserted behind the scenes. Of course, this often manifests itself in/at synchronization, so maybe it is about waits.

Logic

This is not necessarily a problem with record-playback per se as it is with the format in which they are captured in, which is typically tabular. It is really hard to do any sort of conditional logic in scripts in the recorder. If you have to drop to the code to do this then it defeats the exercise of recording in the first place.

Middle intermission

I cannot stress how important the Maintainability aspect of this is. Want to kill the credibility of an automation project? Make it a maintenance burden. And yes, people still turn to record-playback as their automation ‘solution’. Usually for two easily addressable reasons.

Programming is hard [let’s go shopping]

This is a complete cop-out. Automation. Is. Programming. You can run from this, but you cannot escape it. Yes, not everyone tasked with doing automation knows how to program. That’s ok, they can learn. And if they do not want to then you should be questioning whether they should be on the project in the first place. Modern programming languages are huge, but the great thing about automation is you only need to understand a small fraction of the overall language to be successful. (Especially if you have a framework to help you.) And you don’t need to learn Java or C# — even if the application it is automating is. I do/can/have trained people with zero programming experience how to use Python to be effective with automation in a week.

Its.

Not.

Hard.

(If they want to learn)

Locators

I hear a lot that people only use the record functionality of a tool to be able to identify an element of a page then write the script. Just learn your locators and figure it out yourself! Again, tools lack a brain and they may or may not get you the best locator for something. CSS3 and XPath are standards. They are boring to read, but you really should do it. From there you can leverage the developer tools that are showing up in all the browsers to figure out exactly how to grab a specific element.

Summary

This post is simultaneously too long, and not long enough. The big thing to keep in mind is always ‘what am I trying to accomplish with this bit of automation?’. If its one of the three things listed at the top then this category of tool could be right for you. If not though, run, don’t walk, from them an do it right the first time. In code.