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

Starting up Docker containers as part of the build


As we have seen, it's really easy to spin up and shut down the Docker containers. Wouldn't it be useful if we could do that as a part of a build?

In a perfect world, our build process would build our application and then install it in a Docker container. We would then be able to run tests against this container, and if everything worked as expected, we could publish the container in a private Docker registry. We could then take this Docker container and pass it through our promotional model until it hits live. We would then have something in live that is identical to the container that we originally built and tested. Thus, we would know that it works. If we have any problems with it in live, we can easily spin up another instance of this container in a test environment to reproduce the problem. Rather than passing around application installers, we can instead pass around preinstalled and working applications.

Let's have a look at how we can...