Sign In Start Free Trial
Account

Add to playlist

Create a Playlist

Modal Close icon
You need to login to use this feature.
  • Selenium Design Patterns and Best Practices
  • Toc
  • feedback
Selenium Design Patterns and Best Practices

Selenium Design Patterns and Best Practices

By : Kovalenko
3.9 (11)
close
Selenium Design Patterns and Best Practices

Selenium Design Patterns and Best Practices

3.9 (11)
By: Kovalenko

Overview of this book

Selenium WebDriver is a global leader in automated web testing. It empowers users to perform complex testing scenarios with its simple and powerful interface. This guide will provide you with all the skills you need to successfully create a functional Selenium test suite. Starting from the very beginning of the Selenium IDE, this book will show you how to transition into a real programing language such as Ruby or Java. You will quickly learn how to improve your code quality with refactoring and the skills needed to plan for the future development of your website to future-proof your test suite. With ample test examples running against a life-like e-commerce store and detailed step-by-step code review and explanations, you will be ready to test any challenge web developers might throw your way. This book is intended for anyone who wants to create a test suite that is easy to maintain by expanding your knowledge until you feel truly confident and comfortable with Selenium.
Table of Contents (11 chapters)
close
10
Index

Hardcoding input data


Hardcoding test data is just like hardcoding anything in a software; a quick and dirty fix that will forever haunt your nightmares. In Chapter 3, Refactoring Tests, we refactored out some bad practices from our tests. We, however, left test data still hardcoded in the tests. Let's take a look at how each piece of the test data can make our life difficult:

  • URL of the website: Like most web projects, we have several testing environments: staging, localhost, development, and so on. Our tests have the URL of the application hardcoded; thus, without changing the test code, we cannot have the tests execute on both the staging and production environments.

  • Hardcoded product: Typically, different test environments do not share the same identical data such as products. Furthermore, most environments will only have a subset of the products available in production. Test environments in particular will have products that never did and never will exist in production.

  • Private user...

Unlock full access

Continue reading for free

A Packt free trial gives you instant online access to our library of over 7000 practical eBooks and videos, constantly updated with the latest in tech
bookmark search playlist font-size

Change the font size

margin-width

Change margin width

day-mode

Change background colour

Close icon Search
Country selected

Close icon Your notes and bookmarks

Delete Bookmark

Modal Close icon
Are you sure you want to delete it?
Cancel
Yes, Delete