Book Image

Mastering Selenium WebDriver

By : Mark Collin
Book Image

Mastering Selenium WebDriver

By: Mark Collin

Overview of this book

<p>Selenium WebDriver, also known as Selenium 2, is a UI automation tool used by software developers and QA engineers to test their web applications on different web browsers. The Selenium WebDriver API is fully object oriented compared with the deprecated Selenium RC. The WebDriver API provides multi-language support and run tests on all the most popular browsers.</p> <p>In this wide and complex World Wide Web era, this book will teach you how to tame it by gaining an in-depth understanding of the Selenium API.</p> <p>This book starts with how to solve the difficult problems that you will undoubtedly come across as you start using Selenium in an enterprise environment, followed by producing the right feedback when failing, and what the common exceptions are, explain them properly (including the root cause) and tell you how to fix them. You will also see the differences between the three available implicit waits and explicit waits, and learn to working with effective page objects.</p> <p>Moving on, the book shows you how to utilize the Advanced User Interactions API, how you can run any JavaScript you need through Selenium, and how to quickly spin up a Selenium Grid using Docker containers.</p> <p>At the end, the book will discuss the upcoming Selenium W3C specification and how it is going to affect the future of Selenium.</p>
Table of Contents (17 chapters)
Mastering Selenium WebDriver
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Index

A picture paints a thousand words


Even if you have made your tests totally reliable, they will fail occasionally. When this happens it is often very hard to describe what the problem is with words alone. If one of your tests fails, wouldn't it be easier to explain what went wrong if you had a picture of what was happening in the browser when the error happened? I know that, when one of my Selenium tests fails, the first thing I want to know is what was on the screen at the time of failure. If I know what was on the screen at the time of failure I will be able to diagnose the vast majority of issues without having to hunt through a stack trace for a specific line number and then looking at the associated code to try and work out what went wrong. Wouldn't it be nice if we got a screenshot showing what was on the screen every time a test failed? Let's take the project that we built in Chapter 1, Creating a Fast Feedback Loop, and extend it a bit to take a screenshot every time there is a test...