Why Selenium Should Be Your UI Test Tool
Selecting a testing tool is hard work. If you look on vendor websites, you’ll get marketing material promising the world and then a call from their sales staff. If you look on forums, you’ll mostly get people trying to solve problems relating to their product: “Why won’t SuperUITester++ click Save on my Flash application when there are 4 other modals open?”
Let’s take a look at why you might choose Selenium as your UI testing tool with information based on real experience with real software projects—rather than a marketing page.
Why the UI
There are lots of different places you can begin testing software. I like to think of them as different layers in a product, just like sedimentary layers archaeologists dig through when unearthing ancient cities. You want to use the most appropriate tool for each layer of software you are looking at: smaller units, seeing how methods work together, fully formed APIs, simple scenarios in the UI, and complex product usage. All the layers are important; the question is how much of each you want.
The API and everything below that will give you a feel for code quality and some basic functionality. Testing the UI will help you know things from a different perspective: the user’s.
The WebDriver object triggers real events in the browser: mouse clicks, button clicks, entering text, and events from the keyboard. Think of each step as a building block. Stacked together, they can enable a technical team to do some powerful things. Here are a few of the more common reasons for using WebDriver.
Building Automated Checks
Probably the most common reason people elect to use the Selenium suite of tools is to drive a specific set of commands and check status—to see if the user is logged in, if the book goes into the shopping cart, or if a transaction processes.
This includes checks to make sure buttons or labels are present on a page, data that you created saved correctly, procedural aspects of the software under test work accurately, or any number of other attributes of your product.
Put simply, you’ll use WebDriver to ask questions you would normally be able to answer with a yes or a no, and WebDriver will kick out a report with the number of assertions, the ones passing and failing, and where the errors occur.
Once you have finished building your checks, you can run them once or many times and use them as a tool to discover problems, or even unexpected changes, between builds.
The questions you ask in the scripts are binary, but usually the process of writing and running them a few times will uncover important bugs that the scripts aren’t even looking for.