AUTOMATION 15 - GUI 3, introducing Selenium WebDriver

Technical level: **

Through some of these next few posts I'm going to flag up the technical level I believe I'm going to.  This is about 2/5.  I think everyone who is a tester and works with or alongside automation will benefit from.

So far we've looked at identifying page elements, and some very basic manipulation of page elements using Tamper Monkey.  This should be increasing our comfort and sense of "hands on" with the automation.

For the next few sections we'll be looking at Selenium WebDriver, and some tests we can do within this framework.  I'm hoping that by the end of this series you'll understand why we're focusing on Web Driver - over Selenium IDE, which is record and playback.

In a nutshell...

Driven by common computer languages

Selenium WebDriver is powered by a computer language - you can download it on multiple languages such as Java, C#, Ruby, Python.  In this series I'm focusing on Java.

We will also explore by series end why that's incredibly useful.

An API tool

Selenium WebDriver is an API tool - but it's somewhat different to the API's we've looked at previously.  It uses API commands to remote control your browser, and retrieve information from it.  In the examples we've looked at before, we used API commands to remote control part of your test system.  As such, testing with Selenium means we're testing with a complete system under test (your users browser is always external to your system).

Firefox out of the box, but other browsers are available

Out of the box, Selenium WebDriver works on Firefox.  You might be aware that Firefox is updated quite frequently, and likewise Selenium WebDriver has to be updated to keep pace.

In preparing an example, I was unable to get a very simple case to work - turns out my Firefox browser needed an update, and without it Selenium just wouldn't communicate!

Support for other browsers such as Chrome are available, including headless browsers.  Headless browsers such as PhantomJS don't have a graphical interface and return page information in pure html form.  This is really handy for an API driven system like Selenium, which doesn't really need that visual element.  It means if you run your automation with a headless browser, you can perform it much faster as it's stripped down to the bare minimum, such browsers work much faster than say Firefox.  Against that you're not able to screenshot when you have an issue.

I won't be going into any more detail about headless browsers, but if you're interested, you should do further reading.

Looking at Selenium, the commands available fall into several broad categories.  I believe it's useful for testers to be aware of these, even if they don't actually script it, because when you ask your automator to create automation for scenarios for you, you need to be work within these kinds of commands.

Page Manipulation

These kind of commands are a continuation of those we explored previously using TamperMonkey (although we use a different language here).

They are a set of commands to simulate us "doing" something to the page such as,

• Entering test into a field
• Selecting a radio button
• Selecting/deselecting a checkbox
• Choosing an option from a dropdown box
• Pressing a button

Browser control

There are a host of controls which simulate some very basic commands, pretty much anything you can do with your controls in the top band of your browser there's a command for maximise/minimise, read the URL you're on, close/quit, go back.

One of the most useful functions is the navigate command, which takes your browser to the URL you provide.  This is obviously typically step 1 of most tests!

Capture web element

These kind of commands typically get Selenium to "locate" at an area of the web page, from details you provide (such as the ID we used last time).  

Once located, you can run checks on the content at that location - for instance you might open a page, and see if it ever makes a reference to the text "blue aardvark" for instance.

Explicit wait

After issuing a command using Selenium, you have to wait for the browser to respond.

When I was doing "old-style" automation back in 1999, we typically set a wait of about 2 seconds a command to cover this.  These days we want the script to run as fast as possible.

Selenium uses something called an explicit wait - it waits for an event to occur (which you define), it that happens, it will wait up to a time you determine, before moving on anyway.  [Trust me, you don't want to wait indefinitely]

Next time we'll look into installing everything you need for Selenium WebDriver, before moving on to some basic examples.

Extension material

I am using a host of material to prepare this section - primarily sourcing the WebDriver support pages here and here.  I've learned though such pages move around a lot, so be prepared to use Google for a search if this post is quite old.  Hopefully reading this series will help you get more out of those support pages, which I encourage you to visit and read as we work through some examples.

Engel Consulting runs a great course on Selenium WebDriver, and they have provided me support in putting together this series.

Ministry Of Testing has some a useful collection of videos with Richard Bradshaw, but they require membership - which although might seem expensive, talk to your company about (it's an on-demand learning resource, cheaper than sending on a course).