SlideShare a Scribd company logo
Handson Selenium Webdriver With Java A Deep Dive
Into The Development Of Endtoend Tests 1st
Edition Boni Garcia download
https://ebookbell.com/product/handson-selenium-webdriver-with-
java-a-deep-dive-into-the-development-of-endtoend-tests-1st-
edition-boni-garcia-43495464
Explore and download more ebooks at ebookbell.com
Here are some recommended products that we believe you will be
interested in. You can click the link to download.
Handson Selenium Webdriver With Java Boni Garca
https://ebookbell.com/product/handson-selenium-webdriver-with-java-
boni-garca-34883324
Handson Selenium Webdriver With Java Boni Garcia
https://ebookbell.com/product/handson-selenium-webdriver-with-java-
boni-garcia-62628678
Handson Functional Test Automation With Visual Studio 2017 And
Selenium 1st Edition Chaminda Chandrasekara
https://ebookbell.com/product/handson-functional-test-automation-with-
visual-studio-2017-and-selenium-1st-edition-chaminda-
chandrasekara-53001810
Handson Website Scraping With Python Crawling Data Scraping With
Beautiful Soup Selenium And More Ona Prado
https://ebookbell.com/product/handson-website-scraping-with-python-
crawling-data-scraping-with-beautiful-soup-selenium-and-more-ona-
prado-58766302
Python Web Scraping Handson Data Scraping And Crawling Using Pyqt
Selnium Html And Python 2nd Edition 2nd Katharine Jarmul
https://ebookbell.com/product/python-web-scraping-handson-data-
scraping-and-crawling-using-pyqt-selnium-html-and-python-2nd-
edition-2nd-katharine-jarmul-47728702
Handson Systematic Innovation For Business Management First Darrell
Mann
https://ebookbell.com/product/handson-systematic-innovation-for-
business-management-first-darrell-mann-44912938
Handson Ethical Hacking And Network Defense Mindtap Course List 4th
Edition Rob Wilson
https://ebookbell.com/product/handson-ethical-hacking-and-network-
defense-mindtap-course-list-4th-edition-rob-wilson-44975634
Handson Data Analysis With Numpy And Pandas Implement Python Packages
From Data Manipulation To Processing 1st Edition Curtis Miller
https://ebookbell.com/product/handson-data-analysis-with-numpy-and-
pandas-implement-python-packages-from-data-manipulation-to-
processing-1st-edition-curtis-miller-45457142
Handson Design Patterns With Kotlin Gof Reactive Patterns Concurrent
Patterns And More Alexey Soshin
https://ebookbell.com/product/handson-design-patterns-with-kotlin-gof-
reactive-patterns-concurrent-patterns-and-more-alexey-soshin-46191644
Handson Selenium Webdriver With Java A Deep Dive Into The Development Of Endtoend Tests 1st Edition Boni Garcia
Hands-On
Selenium WebDriver
with Java
A Deep Dive into the Development
of End-to-End Tests
Boni García
Foreword by Simon Stewart
C
o
v
e
r
s
S
e
l
e
n
i
u
m
4
Handson Selenium Webdriver With Java A Deep Dive Into The Development Of Endtoend Tests 1st Edition Boni Garcia
Boni García
Hands-On Selenium
WebDriver with Java
A Deep Dive into the Development of
End-to-End Tests
Boston Farnham Sebastopol Tokyo
Beijing Boston Farnham Sebastopol Tokyo
Beijing
978-1-098-11000-0
[LSI]
Hands-On Selenium WebDriver with Java
by Boni García
Copyright © 2022 Boni García. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.
O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are
also available for most titles (https://oreilly.com). For more information, contact our corporate/institu‐
tional sales department: 800-998-9938 or corporate@oreilly.com.
Acquisitions Editor: Suzanne McQuade
Development Editor: Rita Fernando
Production Editor: Kristen Brown
Copyeditor: Piper Editorial Consulting, LLC
Proofreader: JM Olejarz
Indexer: Sam Arnold-Boyd
Interior Designer: David Futato
Cover Designer: Karen Montgomery
Illustrator: Kate Dullea
April 2022: First Edition
Revision History for the First Edition
2022-03-31: First Release
See https://oreilly.com/catalog/errata.csp?isbn=9781098110000 for release details.
The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Hands-On Selenium WebDriver with
Java, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc.
The views expressed in this work are those of the author and do not represent the publisher’s views. While
the publisher and the author have used good faith efforts to ensure that the information and instructions
contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or
omissions, including without limitation responsibility for damages resulting from the use of or reliance
on this work. Use of the information and instructions contained in this work is at your own risk. If any
code samples or other technology this work contains or describes is subject to open source licenses or the
intellectual property rights of others, it is your responsibility to ensure that your use thereof complies
with such licenses and/or rights.
To the most precious thing to me in the world: my children, Pablo and Carlos.
I love you more than anything.
Handson Selenium Webdriver With Java A Deep Dive Into The Development Of Endtoend Tests 1st Edition Boni Garcia
Table of Contents
Foreword. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Part I. Introduction
1. A Primer on Selenium. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Selenium Core Components 3
Selenium WebDriver 5
Selenium Grid 6
Selenium IDE 8
Selenium Ecosystem 10
Language Bindings 10
Driver Managers 11
Locator Tools 12
Frameworks 12
Browser Infrastructure 14
Community 15
Software Testing Fundamentals 16
Levels of Testing 16
Types of Testing 19
Testing Methodologies 21
Test Automation Tools 24
Summary and Outlook 28
v
2. Preparing for Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Requirements 29
Java Virtual Machine 30
Text Editor or IDE 30
Browsers and Drivers 30
Build Tools 31
Optional Software 31
Project Setup 32
Project Layout 32
Dependencies 34
Hello World 45
Using Additional Browsers 48
Summary and Outlook 49
Part II. The Selenium WebDriver API
3. WebDriver Fundamentals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Basic WebDriver Usage 53
WebDriver Creation 53
WebDriver Methods 57
Session Identifier 58
WebDriver Disposal 59
Locating WebElements 59
The Document Object Model (DOM) 59
WebElement Methods 61
Location Strategies 62
Finding Locators on a Web Page 72
Compound Locators 74
Relative Locators 76
What Strategy Should You Use? 80
Keyboard Actions 82
File Uploading 83
Range Sliders 84
Mouse Actions 85
Web Navigation 85
Checkboxes and Radio Buttons 86
User Gestures 86
Right-Click and Double-Click 88
Mouseover 89
Drag and Drop 90
vi | Table of Contents
Click and Hold 91
Copy and Paste 92
Waiting Strategies 94
Implicit Wait 94
Explicit Wait 96
Fluent Wait 98
Summary and Outlook 100
4. Browser-Agnostic Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Executing JavaScript 101
Synchronous Scripts 102
Pinned Scripts 108
Asynchronous Scripts 109
Timeouts 110
Page Loading Timeout 110
Script Loading Timeout 111
Screenshots 112
WebElement Screenshots 115
Window Size and Position 116
Browser History 117
The Shadow DOM 118
Cookies 120
Dropdown Lists 125
Data List Elements 127
Navigation Targets 128
Tabs and Windows 129
Frames and Iframes 131
Dialog Boxes 133
Alerts, Confirms, and Prompts 134
Modal Windows 136
Web Storage 137
Event Listeners 138
WebDriver Exceptions 142
Summary and Outlook 144
5. Browser-Specific Manipulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Browser Capabilities 145
Headless Browser 147
Page Loading Strategies 151
Device Emulation 153
Web Extensions 155
Table of Contents | vii
Geolocation 160
Notifications 162
Browser Binary 165
Web Proxies 166
Log Gathering 168
Get User Media 169
Loading Insecure Pages 171
Localization 173
Incognito 175
Edge in Internet Explorer Mode 175
The Chrome DevTools Protocol 177
CDP Selenium Wrappers 177
CDP Raw Commands 180
Location Context 191
Web Authentication 191
Print Page 193
WebDriver BiDi 194
Summary and Outlook 196
6. Remote WebDriver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Selenium WebDriver Architecture 197
Creation of RemoteWebDriver Objects 199
RemoteWebDriver Constructor 199
RemoteWebDriver Builder 201
WebDriverManager Builder 201
Selenium-Jupiter 202
Selenium Grid 203
Standalone 203
Hub-nodes 207
Fully Distributed 208
Observability 213
Configuration 216
Cloud Providers 217
Browsers in Docker Containers 219
Docker Images for Selenium Grid 220
Selenoid 222
WebDriverManager 224
Selenium-Jupiter 227
Summary and Outlook 228
viii | Table of Contents
Part III. Advanced Concepts
7. The Page Object Model (POM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Motivation 231
The POM Design Pattern 232
Page Objects 234
Robust Page Objects 236
Creating a Domain Specific Language (DSL) 240
Page Factory 242
Summary and Outlook 244
8. Testing Framework Specifics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Parameterized Tests 245
Cross-Browser Testing 252
Categorizing and Filtering Tests 256
Ordering Tests 261
Failure Analysis 265
Retrying Tests 273
Parallel Test Execution 278
Test Listeners 282
Disabled Tests 286
Summary and Outlook 289
9. Third-Party Integrations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
File Download 291
Using Browser-Specific Capabilities 292
Using an HTTP Client 294
Capture Network Traffic 296
Nonfunctional Testing 298
Performance 298
Security 303
Accessibility 306
A/B Testing 307
Fluent API 308
Test Data 309
Reporting 312
Behavior Driven Development 316
Web Frameworks 320
Summary and Outlook 322
Table of Contents | ix
10. Beyond Selenium. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Mobile Apps 325
Mobile Testing 326
Appium 327
REST Services 332
REST Assured 334
Alternatives to Selenium 336
Cypress 336
WebDriverIO 339
TestCafe 340
Puppeteer 341
Playwright 342
Summary and Final Remarks 344
A. What’s New in Selenium 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
B. Driver Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
C. Examples Repository Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
x | Table of Contents
Foreword
In 1999, Kent Beck wrote Extreme Programming Explained. This introduced the
world to Extreme Programming (XP). For many people this was the way they first
heard about Agile software development. Over the next 20 years, many of the ideas
behind the book faded away, but there was one idea that stuck: we should be writing
automated tests that verify our code is working as it should. XP expected these tests
to be written before the app logic, leading to Test Driven Development (TDD).
Today, while strict TDD is seldom practiced, the idea of writing tests is prevalent
(though not always popular!). Most companies now acknowledge the need for some
kind of automated testing. Many of us actually write tests! Even “regular” QA roles
now frequently require people to write code.
In 2004, Jason Huggins started Selenium at a software development consultancy
called Thoughtworks, which specialized in Agile development. Employees were stee‐
ped in XP and were keen proponents of TDD. From the very beginning, Selenium
has been closely associated with testing.
Back then, testing websites in a browser was relatively simple. These were the olden
days, when there were dozens of browsers to choose between and JS was still spelled
“JavaScript.” Sites were small, functionality limited, and the interactions the user
could have via the browser were limited too: maybe just filling out a form and click‐
ing a “submit” button. This is the world that Selenium was born into, and the APIs
and functionality it offered were as focused as the platform it tested.
Then the world discovered XMLHttpRequest hiding in Internet Explorer, it was
implemented in Firefox, and suddenly “Web 2.0” became the hot new buzzword.
Google Maps showed the world what browsers could do, and the world loved it! Web‐
sites started offering more functionality, driven by carefully handcrafted JS. Selenium
adapted and evolved too. I wrote the WebDriver APIs, and these came to the fore.
Although they aimed to lead people in a certain direction, the underlying complexity
of what Selenium was trying to automate meant that it became a more complicated
tool.
xi
As I write this, browsers are more capable, powerful, and flexible than ever before.
We don’t write “websites” any more. We write “web apps,” the current ultimate
expression of that being the “Single Page App” or SPA. These push browsers harder
than ever, but they’re a natural evolution. Fortunately, once again, Selenium has
evolved and grown to allow these kinds of apps to be automated, adding a range of
new features in Selenium 4 to help cope with the new testing needs. Adding this func‐
tionality has made Selenium an even more complicated tool.
But despite having grown more complicated over the years, Selenium is a tool used by
people of all levels of programming comfort and ability. There’s more to writing a
successful Selenium test than “just” learning the APIs. There’s a wealth of technology
that surrounds it, from the test frameworks you can use, to the Design Patterns you
can (and should!) follow when writing the tests, to how we manage the binary depen‐
dencies required by our tests. If we want our tests to run in a reasonable amount of
time, we need to have access to infrastructure that supports this.
There’s just so much to learn, and there’s surprisingly little guidance for how all the
pieces fit together.
That’s why I’m so glad that Boni has written this book. It starts by explaining what
Selenium is, and the various components within it, and then each chapter builds on
the previous ones, gradually introducing more ideas and concepts in a way that feels
natural and obvious.
Better yet, Boni goes further than just discussing how to use the raw APIs. He also
describes the ecosystem of services, tools, and test runners that people need to under‐
stand to get the most from the tool. His experience using Selenium and providing
some of these supporting tools shines through: you’re in the hands of a master here.
The way this book is structured allows anyone using Selenium to dive in at the point
that feels right to them. Just getting started? Then start at the beginning of the book,
as Boni lays out the basics for you in an engaging and approachable way. Maybe
you’re familiar with Selenium but want to know what’s new in Selenium 4, or some of
the less well-known features it offers? Then just jump into the middle of the book;
there’s so much there, even I learned a few things!
One thing that I hope people take away from this book is that Selenium is only part of
the puzzle that is automated testing. Boni covers this too, introducing readers (you!)
to how to integrate it into your test frameworks, to the various unit testing libraries
you might want to use, and to Design Patterns that can help keep your tests maintain‐
able and fresh. After all, although it may take time to write an automated test in the
first place, it can live for years, and being able to work on it with ease is important.
xii | Foreword
This book paves the road to mastering Selenium and using it effectively. I sincerely
hope that this makes using it easier and—dare I say it?—more enjoyable.
— Simon Mavi Stewart
Creator of WebDriver,
Selenium Project Lead 2009–2021,
and coeditor of the W3C WebDriver and
WebDriver BiDi specifications
London, January 2022
Foreword | xiii
Handson Selenium Webdriver With Java A Deep Dive Into The Development Of Endtoend Tests 1st Edition Boni Garcia
Preface
Selenium is an open source umbrella project that enables the automation of web
browsers. The core component of the Selenium project is Selenium WebDriver, a
library for controlling browsers (e.g., Chrome, Firefox, Edge, Safari, or Opera) pro‐
grammatically. Selenium WebDriver provides a cross-browser Application Program‐
ming Interface (API) in several programming languages (officially supported in Java,
JavaScript, Python, C#, or Ruby).
Although we can use Selenium WebDriver for multiple purposes related to browser
automation, its primary use is implementing end-to-end tests for web application
verification. Thousands of organizations and testers now use Selenium worldwide,
and it is one of the leading solutions for end-to-end testing, supporting a multi-
million-dollar industry.
Who Should Read This Book
This book provides a comprehensive summary of the main features of Selenium
WebDriver version 4, using Java as language binding. It reviews the main aspects of
automated web navigation, browser manipulation, web element interaction, user
impersonation, automated driver management, the Page Object Model (POM) design
pattern, use of remote and cloud infrastructure, integration with Docker and third-
party tools, and much more.
The primary audience of this book includes Java coders of different levels (from
beginner to advanced), such as developers, testers, QA engineers, etc. Thus, you need
a basic knowledge of the Java language and object-oriented programming. The final
goal is to have a comprehensive understanding of the main aspects of Selenium Web‐
Driver to create end-to-end tests in Java using different testing frameworks of your
choice (e.g., JUnit or TestNG).
xv
Why I Wrote This Book
Test automation is a software testing technique that leverages automation tools to
control test execution. It allows increased efficiency and effectiveness while ensuring
the overall quality of a software system. In this arena, Selenium WebDriver is the de
facto standard library to develop end-to-end tests for web applications. This book
provides the first complete review of Selenium 4 to date.
The book follows a learn-by-doing approach. To that aim, we review the main fea‐
tures of Selenium WebDriver through ready-to-be-executed test examples. These
examples are publicly available in a GitHub open source repository (https://
github.com/bonigarcia/selenium-webdriver-java). For the sake of completeness, this
repository contains each test example in different flavors of the embedding testing
framework: JUnit 4, JUnit 5 (alone or with Selenium-Jupiter), and TestNG.
Navigating This Book
The content of this book is divided into 3 parts and 10 chapters:
Part I, Introduction
Part I provides technological background on Selenium, test automation, and project
setup. This part, more theoretical than practical, is composed of two chapters:
• Chapter 1, “A Primer on Selenium”, presents the core components of the Sele‐
nium project (WebDriver, Grid, and IDE) and its ecosystem (i.e., the tools and
technologies around Selenium). In addition, this chapter reviews the principles
of end-to-end testing related to Selenium.
• Chapter 2, “Preparing for Testing”, explains how to set up a Java project (Maven
and Gradle) containing end-to-end tests that use the Selenium WebDriver API.
Then, you will learn how to develop your first WebDriver tests using different
testing frameworks: JUnit 4, JUnit 5 (alone or in conjunction with Selenium-
Jupiter), and TestNG.
Part II, The Selenium WebDriver API
Part II provides practical insight into the Selenium WebDriver API. This part is gui‐
ded by tests available in the examples repository and includes the following chapters:
• Chapter 3, “WebDriver Fundamentals”, describes the primary aspects of the Sele‐
nium WebDriver API for carrying out automated interaction with web applica‐
tions. Thus, this chapter reviews several strategies for locating and waiting for
web elements. In addition, you will discover how to impersonate user actions
(i.e., automated interactions using the keyboard and mouse) in a browser.
xvi | Preface
• Chapter 4, “Browser-Agnostic Features”, reviews those aspects of the Selenium
WebDriver API that are interoperable in different browsers. Hence, this chapter
shows how to execute JavaScript, create event listeners, manage windows, make
screenshots, handle the shadow DOM, manipulate cookies, access the browser
history or web storage, or interact with windows, tabs, and iframes, among other
elements.
• Chapter 5, “Browser-Specific Manipulation”, explains those aspects of the Sele‐
nium WebDriver API particular to specific browsers. This group of features cov‐
ers browser capabilities (options, arguments, preferences, etc.), the Chrome
DevTools Protocol (CDP), geolocation functions, basic and web authentication,
printing pages to PDF, or the WebDriver BiDi API.
• Chapter 6, “Remote WebDriver”, describes how to use the Selenium WebDriver
API to control remote browsers. Then, you will learn how to set up and use Sele‐
nium Grid version 4. Finally, you will discover how to use advanced infrastruc‐
ture for Selenium tests in cloud providers (e.g., Sauce Labs, BrowserStack, or
CrossBrowserTesting, among others) and browsers in Docker containers.
Part III, Advanced Concepts
Part III focuses on leveraging the Selenium WebDriver API in different ambits and
use cases. This part includes the following chapters:
• Chapter 7, “The Page Object Model (POM)”, introduces POM, a popular design
pattern used in conjunction with Selenium WebDriver. This pattern allows users
to model web pages using object-oriented classes to ease test maintenance and
reduce code duplication.
• Chapter 8, “Testing Framework Specifics”, reviews several particular features of
the unit testing framework used together with Selenium WebDriver that allow
improvements to different aspects of the overall testing process. To that aim, this
chapter first explains how to carry out cross-browser testing (i.e., reusing the
same test logic for verifying web applications using different browsers) using par‐
ameterized tests and test templates. Then, you will learn how to split tests into
different categories for execution filtering, ordering tests, failure analysis (i.e.,
collecting and analyzing data to determine the cause of a failure), retrying tests,
parallel test execution, test listeners, or disabling tests.
• Chapter 9, “Third-Party Integrations”, reviews different technologies you can use
to enhance your Selenium WebDriver tests, such as reporting tools, test data gen‐
eration, and other frameworks (e.g., Cucumber or Spring). Moreover, this chap‐
ter describes how to use external libraries with Selenium to implement specific
use cases, such as file downloading or nonfunctional tests (such as load, security,
or accessibility).
Preface | xvii
• Chapter 10, “Beyond Selenium”, presents a couple of automation frameworks
related to Selenium: Appium (for mobile testing) and REST Assured (for testing
REST web services). To conclude, we review some of the most relevant current
alternatives to Selenium WebDriver, such as Cypress, WebDriverIO, TestCafe,
Puppeteer, or Playwright.
Conventions Used in This Book
The following typographical conventions are used in this book:
Italic
Indicates new terms, URLs, email addresses, filenames, and file extensions.
Constant width
Used for program listings, as well as within paragraphs to refer to program ele‐
ments such as variable or function names, databases, data types, environment
variables, statements, and keywords.
Constant width bold
Shows commands or other text that the user should type literally.
Constant width italic
Shows text that should be replaced with user-supplied values or by values deter‐
mined by context.
This element signifies a tip or suggestion.
This element signifies a general note.
This element indicates a warning or caution.
xviii | Preface
Using Code Examples
Code examples are available for download at https://github.com/bonigarcia/selenium-
webdriver-java. If you have a technical question or a problem using the code exam‐
ples, please email bookquestions@oreilly.com.
This book is here to help you get your job done. In general, if example code is offered
with this book, you may use it in your programs and documentation. You do not
need to contact us for permission unless you’re reproducing a significant portion of
the code. For example, writing a program that uses several chunks of code from this
book does not require permission. Selling or distributing examples from O’Reilly
books does require permission. Answering a question by citing this book and quoting
example code does not require permission. Incorporating a significant amount of
example code from this book into your product’s documentation does require
permission.
We appreciate, but generally do not require, attribution. An attribution usually
includes the title, author, publisher, and ISBN. For example: “Hands-On Selenium
WebDriver with Java by Boni García (O’Reilly). Copyright 2022 Boni García,
978-1-098-11000-0.”
If you feel your use of code examples falls outside fair use or the permission given
above, feel free to contact us at permissions@oreilly.com.
O’Reilly Online Learning
For more than 40 years, O’Reilly Media has provided technol‐
ogy and business training, knowledge, and insight to help
companies succeed.
Our unique network of experts and innovators share their knowledge and expertise
through books, articles, and our online learning platform. O’Reilly’s online learning
platform gives you on-demand access to live training courses, in-depth learning
paths, interactive coding environments, and a vast collection of text and video from
O’Reilly and 200+ other publishers. For more information, visit https://oreilly.com.
How to Contact Us
Please address comments and questions concerning this book to the publisher:
O’Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
Preface | xix
800-998-9938 (in the United States or Canada)
707-829-0515 (international or local)
707-829-0104 (fax)
We have a web page for this book, where we list errata, examples, and any additional
information. You can access this page at https://oreil.ly/handsOn_SeleniumWDJ.
Email bookquestions@oreilly.com to comment or ask technical questions about this
book.
For news and information about our books and courses, visit https://oreilly.com.
Find us on Facebook: https://facebook.com/oreilly.
Follow us on Twitter: https://twitter.com/oreillymedia.
Watch us on YouTube: https://www.youtube.com/oreillymedia.
Acknowledgments
First, I want to thank the team at O’Reilly for making this book a reality. Their edito‐
rial support has been exemplary through every stage of this journey.
I also want to recognize the technical reviewers who helped with this book. Their val‐
uable feedback and expert advice improved its quality significantly: Diego Molina
(staff software engineer at Sauce Labs and technical lead of the Selenium project), Fil‐
ippo Ricca (associate professor of computer science at Università di Genova), Andrea
Stocco (postdoctoral researcher at Software Institute in Università della Svizzera ital‐
iana), Ivan Krutov (software developer at Aerokube), and Daniel Hinojosa (inde‐
pendent consultant, programmer, instructor, speaker, and author)—thank you very
much.
Lastly, I would like to acknowledge the contribution of Simon Stewart (creator of
WebDriver and Selenium project lead until 2021). Thanks a lot, Simon, for writing
the foreword on this book and for your priceless feedback about its content. But
mainly, I want to recognize your work during all these years leading the Selenium
project. Your contributions to the automation testing community are already part of
software history.
xx | Preface
PART I
Introduction
Selenium is an open source umbrella project composed of three core components:
WebDriver, Grid, and IDE. Selenium provides advanced capabilities for browser
automation that practitioners typically use for implementing end-to-end tests for web
applications. This first part of the book is a comprehensive overview of the Selenium
project and its ecosystem. Moreover, it provides a primer on the software testing
theory, focusing on its practical applications for Selenium WebDriver. Finally, you
will discover how to set up a project (using Maven or Gradle) for developing Web‐
Driver tests. For the sake of completeness, I cover different alternatives regarding the
unit testing framework used to embed the calls to the Selenium WebDriver API,
namely, JUnit 4, JUnit 5 (alone or extended by Selenium-Jupiter), and TestNG.
Handson Selenium Webdriver With Java A Deep Dive Into The Development Of Endtoend Tests 1st Edition Boni Garcia
CHAPTER 1
A Primer on Selenium
Selenium is an open source suite composed of a set of libraries and tools that enable
the automation of web browsers. We can see Selenium as an umbrella project with
three core components: WebDriver, Grid, and IDE (Integrated Development Envi‐
ronment). Selenium WebDriver is a library that allows the driving of browsers pro‐
grammatically. Thus, we can use Selenium WebDriver to navigate websites and
interact with web pages (e.g., clicking on links, filling in forms, etc.) as a real user
would do, in an automated fashion. The primary use of Selenium WebDriver is the
automated testing of web applications. Other Selenium uses include the automation
of web-based administration tasks or web scraping (automated web data extraction).
This chapter provides a comprehensive overview of the Selenium core components:
WebDriver, Grid, and IDE. Then, it reviews the Selenium ecosystem, i.e., other tools
and technologies around it. Finally, it analyzes the foundations of software testing
related to Selenium.
Selenium Core Components
Jason Huggins and Paul Hammant created Selenium in 2004 while working in
Thoughtworks. They chose the name “Selenium” as a counterpart to Mercury, an
existing testing framework developed by Hewlett-Packard. The name is significant
because the chemical selenium is known for reducing the toxicity of mercury.
That initial version of Selenium (known today as Selenium Core) is a JavaScript
library that impersonates user actions in web applications. Selenium Core interprets
the so-called Selenese commands to achieve this task. These commands are encoded
as an HTML table composed of three parts: command (action executed in a web
browser, such as opening a URL or clicking a link), target (locator that identifies a
3
web element, such as the attribute of a given component), and value (optional data,
such as the text typed into a web-form field).
Huggins and Hammant added a scripting layer to Selenium Core in a new project
called Selenium Remote Control (RC). Selenium RC follows a client-server architec‐
ture. Clients use a binding language (such as Java or JavaScript) to send Selenese
commands over HTTP to an intermediate proxy called the Selenium RC Server. This
server launches web browsers on demand, injecting the Selenium Core library into a
website and proxying requests from clients to Selenium Core. In addition, the Sele‐
nium RC Server masks the target website to the same local URL of the injected Sele‐
nium Core library to avoid same-origin policy concerns. This approach was a game-
changer for browser automation at that time, but it had significant limitations. First,
because JavaScript is the underlying technology to support automation, some actions
are not permitted since JavaScript does not allow them—for instance, uploading and
downloading files or handling pop-ups and dialogs, to name a few. Besides, Selenium
RC introduces a relevant overhead that impacts its performance.
In parallel, Simon Stewart created the project WebDriver in 2007. WebDriver and
Selenium RC were equivalent from a functional perspective, i.e., both projects allow
programmers to impersonate web users using a programming language. Neverthe‐
less, WebDriver uses the native support of each browser to carry out the automation,
and therefore, its capabilities and performance are far superior to RC. In 2009, after a
meeting between Jason Huggins and Simon Stewart at the Google Test Automation
Conference, they decided to merge Selenium and WebDriver in a single project. The
new project was called Selenium WebDriver or Selenium 2. This new project uses a
communication protocol based on HTTP combined with the native automation sup‐
port on the browser. That approach is still the basis of Selenium 3 (released in 2016)
and Selenium 4 (released in 2021). Now we refer to Selenium RC and Core as “Sele‐
nium 1,” and its use is discouraged in favor of Selenium WebDriver. This book focu‐
ses on the latest version of Selenium WebDriver to date, i.e., version 4.
Appendix A summarizes the novelties shipped with Selenium 4.
This appendix also contains a migration guide for bumping from
Selenium 3 to 4.
Today, Selenium is a well-known automation suite composed of three subprojects:
WebDriver, Grid, and IDE. The following subsections present the main characteris‐
tics of each one.
4 | Chapter 1: A Primer on Selenium
Selenium WebDriver
Selenium WebDriver is a library that allows the controlling of web browsers automat‐
ically. To that aim, it provides a cross-platform API in different language bindings.
The official programming languages supported by Selenium WebDriver are Java,
JavaScript, Python, Ruby, and C#. Internally, Selenium WebDriver uses the native
support implemented by each browser to carry out the automation process. For this
reason, we need to place a component called driver between the script using the Sele‐
nium WebDriver API and the browser. Table 1-1 summarizes the browsers and driv‐
ers officially supported by Selenium WebDriver.
The name Selenium is widely used to refer to the library for
browser automation. Since this term is also the name of the
umbrella project, I use Selenium in this book to identify the
browser automation suite, which is composed of three compo‐
nents: Selenium WebDriver (library), Selenium Grid (infrastruc‐
ture), and Selenium IDE (tool).
Table 1-1. Browsers and drivers supported by Selenium WebDriver
Browser Driver Operating
system
Maintainer Download
Chrome/
Chromium
chromedriver Windows/
macOS/Linux
Google https://chromedriver.chromium.org
Edge msedgedriver Windows/
macOS/Linux
Microsoft https://developer.microsoft.com/en-us/microsoft-edge/tools/
webdriver
Firefox geckodriver Windows/
macOS/Linux
Mozilla https://github.com/mozilla/geckodriver
Opera operadriver Windows/
macOS/Linux
Opera
Software AS
https://github.com/operasoftware/operachromiumdriver
Internet
Explorer
IEDriverServer Windows Selenium
project
https://www.selenium.dev/downloads
Safari safaridriver macOS Apple Built-in
Drivers (e.g., chromedriver, geckodriver, etc.) are platform-dependent binary files
that receive commands from a WebDriver script and translate them into some
browser-specific language. In the first releases of Selenium WebDriver (i.e., in Sele‐
nium 2), these commands (also known as the Selenium protocol) were JSON messages
over HTTP (the so-called JSON Wire Protocol). Nowadays, this communication (still
JSON over HTTP) follows a standard specification named W3C WebDriver. This
specification is the preferred Selenium protocol as of Selenium 4.
Selenium Core Components | 5
Figure 1-1 summarizes the basic architecture of Selenium WebDriver we have seen so
far. As you can see, this architecture has three tiers. First, we find a script using the
Selenium WebDriver API (Java, JavaScript, Python, Ruby, or C#). This script sends
W3C WebDriver commands to the second layer, in which we find the drivers. This
figure shows the specific case of using chromedriver (to control Chrome) and gecko‐
driver (to control Firefox). Finally, the third layer contains the web browsers. In the
case of Chrome, the native browser follows the DevTools Protocol. DevTools is a set of
developer tools for browsers based on the Blink rendering engine, such as Chrome,
Chromium, Edge, or Opera. The DevTools Protocol is based on JSON-RPC messages
and allows inspecting, debugging, and profiling these browsers. In Firefox, the native
automation support uses the Marionette protocol. Marionette is a remote protocol
based on JSON, allowing instrumenting and controlling web browsers based on the
Gecko engine (such as Firefox).
Figure 1-1. Selenium WebDriver architecture
Overall, Selenium WebDriver allows controlling web browsers as a user would, but
programmatically. To that aim, the Selenium WebDriver API provides a wide variety
of features to navigate web pages, interact with web elements, or impersonate user
actions, among many other capabilities. The target application is web-based, such as
static websites, dynamic web applications, Single Page Applications (SPA), complex
enterprise systems with a web interface, etc.
Selenium Grid
The second project of the Selenium family is Selenium Grid. Philippe Hanrigou
started the development of this project in 2008. Selenium Grid is a group of net‐
worked hosts that provides browser infrastructure for Selenium WebDriver. This
infrastructure enables the (parallel) execution of Selenium WebDriver scripts with
remote browsers of a different nature (types and versions) in multiple operating
systems.
6 | Chapter 1: A Primer on Selenium
Figure 1-2 shows the basic architecture of Selenium Grid. As you can see, a group of
nodes provides browsers used by Selenium scripts. These nodes can use different
operating systems (as we saw in Table 1-1) with various installed browsers. The cen‐
tral entry point to this Grid is the Hub (also known as Selenium Server). This server-
side component keeps track of the nodes and proxies requests from the Selenium
scripts. Like in Selenium WebDriver, the W3C WebDriver specification is the stan‐
dard protocol for the communication between these scripts and the Hub.
Figure 1-2. Selenium Grid hub-nodes architecture
The hub-nodes architecture in Grid has been available since Selenium 2. This archi‐
tecture is also present in Selenium 3 and 4. Nevertheless, this centralized architecture
can lead to performance bottlenecks if the number of requests to the Hub is high.
Selenium 4 provides a fully distributed flavor of Selenium Grid to avoid this problem.
This architecture implements advanced load balancing mechanisms to avoid over‐
loading any component.
Chapter 6 describes how to set up Selenium Grid following the
classical approach (based on a hub and set of nodes). This chapter
also covers the standalone mode (i.e., hub and node(s) hosted in
the same machine) and the fully distributed architecture.
Selenium Core Components | 7
Selenium IDE
Selenium IDE is the last core component of the Selenium suite. Shinya Kasatani cre‐
ated this project in 2006. Selenium IDE is a tool that implements the so-called Record
and Playback (R&P) automation technique. As the name suggests, this technique has
two steps. First, in Selenium IDE, the record part captures user interactions with a
browser, encoding these actions as Selenium commands. Second, we use the gener‐
ated Selenium script to execute a browser session automatically (playback).
This early version of Selenium IDE was a Firefox plug-in that embedded Selenium
Core to record, edit, and play back Selenium scripts. These early versions were XPI
modules (i.e., a technology used to create Mozilla extensions). As of version 55
(released in 2017), Firefox migrated support for add-ons to the W3C Browser Exten‐
sion specification. As a result, Selenium IDE was discontinued, and for some time, it
has not been possible to use it. The Selenium team rewrote Selenium IDE following
the Browser Extensions recommendation to solve this problem. Thanks to this, we
can now use Selenium IDE in multiple browsers, such as Chrome, Edge, and Firefox.
Figure 1-3 shows the new Selenium IDE GUI (Graphical User Interface).
Using this GUI, users can record interactions with a browser and edit and execute the
generated script. Selenium IDE encodes each interaction in different parts: a com‐
mand (i.e., the action executed in the browser), a target (i.e., the locator of the web
element), and a value (i.e., the data handled). Optionally, we can include a description
of the command. Figure 1-3 shows a recorded example of these steps:
1. Open website (https://bonigarcia.dev/selenium-webdriver-java). We will use this
website as the practice site in the rest of the book.
2. Click on the link with the text “GitHub.” As a result, the navigation moves to the
examples repository source code.
3. Assert that the book title (Hands-On Selenium WebDriver with Java) is present on
the web page.
4. Close the browser.
8 | Chapter 1: A Primer on Selenium
Figure 1-3. Selenium IDE showing an example of a recorded script
Once we have created a script in Selenium IDE, we can export this script as a Sele‐
nium WebDriver test. For instance, Figure 1-4 shows how to convert the presented
example as a JUnit test case. Finally, we can save the project on our local machine.
The resulting project for this sample is available in the examples GitHub repository.
The Selenium project is porting Selenium IDE to Electron at the
time of this writing. Electron is an open source framework based
on Chromium and Node.js that allows desktop application
development.
Selenium Core Components | 9
Figure 1-4. Exporting a Selenium IDE script to a JUnit test case
Selenium Ecosystem
Software ecosystems are collections of elements interacting with a shared market
underpinned by a common technological background. In the case of Selenium, its
ecosystem involves the official core projects and other related projects, libraries, and
actors. This section reviews the Selenium ecosystem, divided into the following cate‐
gories: language bindings, driver managers, frameworks, browser infrastructure, and
community.
Language Bindings
As we already know, the Selenium project maintains various language bindings for
Selenium WebDriver: Java, JavaScript, Python, Ruby, and C#. Nevertheless, other lan‐
guages are also available. Table 1-2 summarizes these language bindings for Selenium
WebDriver maintained by the community.
Table 1-2. Unofficial language bindings for Selenium WebDriver
Name Language License Maintainer Website
hs-webdriver Haskell BSD-3-Clause Adam Curtis https://github.com/kallisti-dev/hs-webdriver
php-webdriver PHP MIT Facebook,
community
https://github.com/php-webdriver/php-webdriver
RSelenium R AGPLv3 rOpenSci https://github.com/ropensci/RSelenium
10 | Chapter 1: A Primer on Selenium
Name Language License Maintainer Website
Selenium Go MIT Miki Tebeka https://github.com/tebeka/selenium
Selenium-Remote-
Driver
Perl Apache 2.0 George S. Baugh https://github.com/teodesian/Selenium-Remote-Driver
webdriver.dart Dart Apache 2.0 Google https://github.com/google/webdriver.dart
wd JavaScript Apache 2.0 Adam Christian https://github.com/admc/wd
Driver Managers
Drivers are mandatory components to control web browsers natively with Selenium
WebDriver (see Figure 1-1). For this reason, before using the Selenium WebDriver
API, we need to manage these drivers. Driver management is the process of down‐
loading, setting up, and maintaining the proper driver for a given browser. The usual
steps in the driver management procedure are:
1. Download
Each browser has its own driver. For example, we use chromedriver for control‐
ling Chrome or geckodriver for Firefox (see Table 1-1). The driver is a platform-
specific binary file. Therefore, we need to download the proper driver for a given
operating system (typically, Windows, macOS, or Linux). In addition, we need to
consider the driver version since a driver release is compatible with a given
browser version (or range). For example, to use Chrome 91.x, we need to
download chromedriver 91.0.4472.19. We usually find the browser-driver com‐
pliance in the driver documentation or release notes.
2. Setup
Once we have the proper driver, we need to make it available in our Selenium
WebDriver script.
3. Maintenance
Modern web browsers (e.g., Chrome, Firefox, or Edge) upgrade themselves auto‐
matically and silently, without prompting the user. For this reason, and concern‐
ing Selenium WebDriver, we need to maintain the browser-driver version
compatibility in time for these so-called evergreen browsers.
As you can see, the driver maintenance process can be time-consuming. Further‐
more, it can cause problems for Selenium WebDriver users (e.g., failed tests due to
browser-driver incompatibility after an automatic browser upgrade). For this reason,
the so-called driver managers aim to carry out the driver management process in an
automated fashion to some extent. Table 1-3 summarizes the available driver manag‐
ers for different language bindings.
Selenium Ecosystem | 11
Table 1-3. Driver managers for Selenium WebDriver
Name Language License Maintainer Website
WebDriverManager Java Apache 2.0 Boni García https://github.com/bonigarcia/webdrivermanager
webdriver-manager JavaScript MIT Google https://www.npmjs.com/package/webdriver-manager
webdriver-manager Python Apache 2.0 Serhii Pirohov https://pypi.org/project/webdriver-manager
WebDriverManager.Net C# MIT Aliaksandr
Rasolka
https://github.com/rosolko/WebDriverManager.Net
webdrivers Ruby MIT Titus Fortner https://github.com/titusfortner/webdrivers
In this book, I recommend using WebDriverManager because it
automates the entire driver maintenance process (i.e., download,
setup, and maintenance). See Appendix B for further information
about automated and manual driver management.
Locator Tools
The Selenium WebDriver API provides different ways to locate web elements (see
Chapter 3): by attribute (id, name, or class), by link text (complete or partial), by tag
name, by CSS (Cascading Style Sheets) selector, or by XML Path Language (XPath).
Specific tools can help to identify and generate these locators. Table 1-4 shows some
of these tools.
Table 1-4. Locators tools summary
Name Type License Maintainer Website
Chrome DevTools Built-in browser
tool
Proprietary
freeware, based
on open source
Google https://developer.chrome.com/docs/devtools
Firefox Developer
Tools
Built-in browser
tool
MPL 2.0 Mozilla https://developer.mozilla.org/en-US/docs/Tools
Cropath Browser
extension
Freeware AutonomIQ https://autonomiq.io/deviq-chropath.html
SelectorsHub Browser
extension
Freeware Sanjay Kumar https://selectorshub.com
POM Builder Browser
extension
Freeware LogiGear
Corporation
https://pombuilder.com
Frameworks
In software engineering, a framework is a set of libraries and tools used as a concep‐
tual and technological base and support for software development. Selenium is the
foundation for frameworks that wrap, enhance, or complement its default features.
Table 1-5 contains some of these frameworks and libraries based on Selenium.
12 | Chapter 1: A Primer on Selenium
Table 1-5. Testing frameworks and libraries based on Selenium
Name Language Description License Maintainer Website
CodeceptJS JavaScript Multi-backend testing
framework that models
browser interactions as
simple steps from a user
perspective
MIT Michael
Bodnarchuk
https://codecept.io
FluentSelenium Java Fluent API for Selenium
WebDriver
Apache 2.0 Paul Hammant https://github.com/Selenium
HQ/fluent-selenium
FluentLenium Java Website and mobile
automation framework to
create readable and
reusable WebDriver tests
Apache 2.0 FluentLenium
team
https://fluentlenium.com
Healenium Java Library for improving the
stability of Selenium tests
by using machine learning
algorithms to analyze web
and mobile web elements
Apache 2.0 Anna
Chernyshova
and Dmitriy
Gumeniuk
https://healenium.io
Helium Python High-level API based on
Selenium WebDriver
MIT Michael
Herrmann
https://github.com/mherrma
nn/selenium-python-helium
QAF (QMetry
Automation
Framework)
Java Test automation platform
for web and mobile
applications
MIT Chirag Jayswal https://qmetry.github.io/qaf
Lightning Java Lightweight Selenium
WebDriver client for Java
Apache 2.0 FluentLenium https://github.com/aerokube
/lightning-java
Nerodia Python Python port of the Watir
Ruby gem
MIT Lucas Tierney https://nerodia.readthedocs.i
o
Robot
Framework
Python,
Java, .NET,
and others
Generic automation
framework based on
human-readable test
cases
Apache 2.0 Robot
Framework
Foundation
https://robotframework.org
Selenide team Java Fluent, concise API for
Selenium WebDriver
MIT Selenide team https://selenide.org
SeleniumBase Python Browser automation
framework based on
WebDriver and pytest
MIT Michael Mintz https://seleniumbase.io
Watir (Web
Application
Testing in Ruby)
Ruby Gem library based on
WebDriver for automating
web browsers
MIT Titus Fortner http://watir.com
WebDriverIO JavaScript Test automation
framework based
WebDriver and Appium
MIT Christian
Bromann
https://webdriver.io
Nightwatch.js JavaScript Integrated end-to-end
testing framework based
on the W3C WebDriver
MIT Andrei Rusu https://nightwatchjs.org
Selenium Ecosystem | 13
Name Language Description License Maintainer Website
Applitools Java,
JavaScript,
C#, Ruby,
PHP, Python
Test automation
framework for visual user
interface regression and
A/B testing. It provides
SDKs for Selenium,
Appium, and others
Commercial Applitools team https://applitools.com
Katalon Studio Java,
Groovy
Test automation platform
leveraging Selenium
WebDriver, Appium, and
cloud providers
Commercial Katalon team https://www.katalon.com
TestProject Java, C#,
Python
Test automation platform
for web and mobile apps
built on top of Selenium
and Appium
Commercial TestProject
team
https://testproject.io
Browser Infrastructure
We can use Selenium WebDriver to control local browsers installed in the machine
running the WebDriver script. Also, Selenium WebDriver can drive remote web
browsers (i.e., those executed in other hosts). In this case, we can use Selenium Grid
to support the remote browser infrastructure. Nevertheless, this infrastructure can be
challenging to create and maintain.
Alternatively, we can use a cloud provider to outsource the responsibility for support‐
ing the browser infrastructure. In the Selenium ecosystem, a cloud provider is a
company or product that supplies managed services for automated testing.
These companies typically offer commercial solutions for web and mobile testing.
The users of a cloud provider request on-demand browsers of different types, ver‐
sions, and operating systems. Also, these providers typically offer additional services
for easing the testing and monitoring activities, such as access to session recordings
or analysis capabilities, to name a few. Some of the most relevant cloud providers for
Selenium nowadays are Sauce Labs, BrowserStack, LambdaTest, CrossBrowserTest‐
ing, Moon Cloud, TestingBot, Perfecto, or Testinium.
Another solution we can use to support the browser infrastructure for Selenium is
Docker. Docker is an open source software technology that allows users to pack and
run applications as lightweight, portable containers. The Docker platform has two
main components: the Docker Engine, a tool for creating and running containers, and
the Docker Hub, a cloud service for distributing Docker images. In the Selenium
domain, we can use Docker to pack and execute containerized browsers. Table 1-6
presents a summary of relevant projects using Docker in the Selenium ecosystem.
14 | Chapter 1: A Primer on Selenium
Table 1-6. Docker resources for Selenium
Name Description License Maintainer Website
docker-
selenium
Official Docker images for
Selenium Grid
Apache 2.0 Selenium
project
https://github.com/seleniumhq/docker-seleni
um
Selenoid Lightweight Golang
implementation of Selenium Hub
running browsers in Docker
(images available on Docker Hub)
Apache 2.0 Aerokube https://aerokube.com/selenoid
Moon Enterprise Selenium cluster that
use Docker and Kubernetes
Commercial Aerokube https://aerokube.com/moon
Callisto Open source Kubernetes-native
implementation of Selenium Grid
MIT Aerokube https://github.com/wrike/callisto
Community
Due to its collaborative nature, software development needs the organization and
interaction of many participants. In the open source domain, we can measure the
success of a project by the relevance of its community. Selenium is supported by a
large community of many different participants worldwide. Table 1-7 presents a sum‐
mary of several Selenium resources grouped into the following categories: official
documentation, development, support, and events.
Table 1-7. Selenium community resources
Category Description Website
Official documentation User guide https://www.selenium.dev/documentation
Blog https://www.selenium.dev/blog
Wiki https://github.com/seleniumhq/selenium/wiki
Ecosystem https://www.selenium.dev/ecosystem
Development Source code https://github.com/seleniumhq/selenium
Issues https://github.com/seleniumhq/selenium/issues
Governance https://www.selenium.dev/project
Support User group https://groups.google.com/group/selenium-users
Slack https://seleniumhq.slack.com
IRC https://webchat.freenode.net/#selenium
StackOverflow https://stackoverflow.com/questions/tagged/selenium
Reddit https://www.reddit.com/r/selenium
Events Conference https://www.selenium.dev/categories/conference
Meetups https://www.meetup.com/topics/selenium
Selenium Ecosystem | 15
Software Testing Fundamentals
Software testing (or simply testing) consists of the dynamic evaluation of a piece of
software, called System Under Test (SUT), through a finite set of test cases (or simply
tests), giving a verdict about it. Testing implies the execution of SUT using specific
input values to assess the outcome or expected behavior.
At first glance, we distinguish two separate categories of software testing: manual and
automated. On the one hand, in manual testing, a person (typically a software engi‐
neer or the final user) evaluates the SUT. On the other hand, in automated testing, we
use specific software tools to develop tests and control their execution against the
SUT. Automated tests allow the early detection of defects (usually called bugs) in the
SUT while providing a large number of additional benefits (e.g., cost savings, fast
feedback, test coverage, or reusability, to name a few). Manual testing can also be a
valuable approach in some cases, for example, in exploratory testing (i.e., human test‐
ers freely investigate and evaluate the SUT).
There is no universal classification for the numerous forms of test‐
ing presented in this section. These concepts are subject to contin‐
uous evolution and debate, just like software engineering. Consider
it a proposal that can fit into a large number of projects.
Levels of Testing
Depending on the size of the SUT, we can define different levels of testing. These levels
define several categories in which software teams divide their testing efforts. In this
book, I propose a stacked layout to represent the different levels (see Figure 1-5). The
lower levels of this structure represent the tests aimed at verifying small pieces of soft‐
ware (called units). As we ascend in the stack, we find other tiers (e.g., integration,
system, etc.) in which the SUT integrates more and more components.
Figure 1-5. Stack representation of the different levels of testing
16 | Chapter 1: A Primer on Selenium
The lowest level of this stack is unit testing. At this level, we assess individual units of
software. A unit is a particular observable element of behavior. For instance, units are
typically methods or classes in object-oriented programming and functions in func‐
tional programming. Unit testing aims to verify that each unit behaves as expected.
Automated unit tests usually run very fast since each test executes a small amount of
code in isolation. To achieve this isolation, we can use test doubles, pieces of software
that replace the dependent components of a given unit. For example, a popular type
of test double in object-oriented programming is the mock object. A mock object
mimics an actual object using some programmed behavior.
The next level in Figure 1-5 is integration testing. At this level, different units are com‐
posed to create composite components. Integration testing aims to assess the interac‐
tion between the involved units and expose defects in their interfaces.
Then, at the system testing and end-to-end (E2E) levels, we test the software system as
a whole. We need to deploy the SUT and verify its high-level features to carry out
these levels. The difference between system/end-to-end and integration testing is that
the former involves all the system components and the final user (typically imperso‐
nated). In other words, system and end-to-end testing assess the SUT through the
User Interface (UI). This UI can be graphical (GUI) or nongraphical (e.g., text-based
or other types).
The Test Pyramid
The test pyramid is a classical representation of the levels of testing. Mike Cohn first
coined this concept in 2009. In his original conception, Cohn recommended a large
number of unit tests as the basis of testing efforts. The following levels (e.g., integra‐
tion tests) are less numerous in each stage but typically more expensive (in terms of
development and maintenance effort) and slow (in terms of execution time). This
proposal might be impractical for many projects because unit tests are not always
from a comprehensive testing suite. For this reason, other authors define different
shapes for the levels of testing, such as the testing trophy (in which the intermediate
layer, i.e., the integration test, is the largest). Since the relevance of the different test
categories can vary from one project to another, I use a basic stack structure to repre‐
sent the different levels of testing.
Figure 1-6 illustrates the difference between system and end-to-end testing. As you
can see, on the one hand, end-to-end testing involves the software system and its
dependent subsystems (e.g., database or external services). On the other hand, system
testing comprises only the software system, and these external dependencies are typi‐
cally mocked.
Software Testing Fundamentals | 17
Figure 1-6. Component-based representation of the different levels of testing
Acceptance testing is the top tier of the presented stack. At this level, the final user par‐
ticipates in the testing process. The objective of acceptance testing is to decide
whether the software system meets end-user expectations. As you can see in
Figure 1-6, like end-to-end testing, acceptance testing validates the whole system and
its dependencies. Therefore, acceptance tests also use the UI to carry out the SUT
validation.
The primary purpose of Selenium WebDriver is to implement end-
to-end tests. Nevertheless, we can use WebDriver to carry out sys‐
tem testing when mocking the backend calls made by the website
under test. Moreover, we can use Selenium WebDriver in conjunc‐
tion with a Behavior-Driven Development (BDD) tool to imple‐
ment acceptance tests (see Chapter 9).
18 | Chapter 1: A Primer on Selenium
Verification and Validation
The down levels of the test stack we have seen (unit, integration, system, and end-to-
end testing) belong to development testing. Development testing is a process carried
out by the team that produces the software system (i.e., developers, testers, etc.) dur‐
ing the construction phase of the software development lifecycle. Development test‐
ing is a type of verification since we assess that the software meets its stated functional
and nonfunctional requirements (i.e., its specification). Using the classical definition
stated by Barry Boehm in 1984, verification allows answering the following question:
“Are we building the product right?”
The top level of the test stack represented in Figure 1-5 (i.e., acceptance testing)
belongs to user testing since it involves the final user in the testing process. Accept‐
ance testing is a type of validation because its objective is to prove the software system
meets end-user expectations. Validation is a more general process than verification
since the system specification does not always reflect the user’s real wishes or needs.
Thus, according to Boehm, validation allows answering the question “Are we building
the right product?”
Types of Testing
Depending on the strategy for designing test cases, we can implement different types
of tests. The two principal types of testing are:
Functional testing (also known as behavioral or closed-box testing)
Evaluates the compliance of a piece of software with the expected behavior (i.e.,
its functional requirements).
Structural testing (also known as clear-box testing)
Determines if the program-code structure is faulty. To that aim, testers should
know the internal logic of a piece of software.
The difference between these testing types is that functional tests are responsibility-
based, while structural tests are implementation-based. Both types can be performed
at any test level (unit, integration, system, end-to-end, or acceptance). Nevertheless,
structural tests are commonly done at the unit or integration level since these levels
enable more direct control of the code execution flow.
Black-box and white-box testing are other names for functional and
structural testing, respectively. Nevertheless, these designations are
not recommended since the tech industry is trying to adopt more
inclusive terms and use neutral terminology instead of potentially
harmful language.
Software Testing Fundamentals | 19
There are different flavors of functional testing. For example:
UI testing (known as GUI testing when the UI is graphical)
Evaluates if the visual elements of an application meet the expected functionality.
Note that UI testing is different from the system and end-to-end testing levels
since the former tests the interface itself, and the latter evaluates the whole sys‐
tem through the UI.
Negative testing
Evaluates the SUT under unexpected conditions (e.g., expected exceptions). This
term is the counterpart of the regular functional testing (sometimes called posi‐
tive testing), in which we assess if the SUT behaves as expected (i.e., its happy
path).
Cross-browser testing
This is specific for web applications. It aims to verify the compatibility of websites
and applications in different web browsers (types, versions, or operating
systems).
A third miscellaneous testing type, nonfunctional testing, includes testing strategies
that assess the quality attributes of a software system (i.e., its nonfunctional require‐
ments). Common methods of nonfunctional testing include, but are not limited to:
Performance testing
Assesses different metrics of software systems, such as response time, stability,
reliability, or scalability. The objective of performance testing is not finding bugs
but finding system bottlenecks. There are two common subtypes of performance
testing:
Load testing
Increases the usage on the system by simulating multiple concurrent users to
verify if it can operate in the defined boundaries.
Stress testing
Exercises a system beyond its operational capacity to identify the actual lim‐
its at which the system breaks.
Security testing
Tries to evaluate security concerns, such as confidentiality (disclosure of infor‐
mation protection), authentication (ensuring the user identity), or authorization
(determining user rights and privileges), among others.
Usability testing
Evaluates how user-friendly a software application is. This assessment is also
called User eXperience (UX) testing. A subtype of usability testing is:
20 | Chapter 1: A Primer on Selenium
A/B testing
Compares different variations of the same application to determine which
one is more effective for its end users.
Accessibility testing
Evaluates if a system is usable by people with disabilities.
We use Selenium WebDriver primarily to implement functional
tests (i.e., interacting with a web application UI to assess the appli‐
cation behavior). It is unlikely to use WebDriver to implement
structural tests. In addition, although it is not its principal usage,
we can use WebDriver to implement nonfunctional tests, e.g., for
load, security, accessibility, or localization (assessment of specific
locale settings) testing (see Chapter 9).
Testing Methodologies
The software development lifecycle is the set of activities, actions, and tasks required to
create software systems in software engineering. The moment at which software engi‐
neers design and implement test cases in the overall development lifecycle depends
on the specific development process (such as iterative, waterfall, or agile, to name a
few). Two of the most relevant testing methodologies are:
Test Driven Development (TDD)
TDD is a methodology in which we design and implement tests before the actual
software design and implementation. At the beginning of the 21st century, TDD
became popular with the rise of agile software development methodologies, such
as Extreme Programming (XP). In TDD, a developer first writes an (initially
failing) automated test for a given feature. Then, the developer creates a piece of
code to pass that test. Finally, the developer refactors the code to achieve or
improve readability and maintainability.
Test Last Development (TLD)
TLD is a methodology in which we design and implement tests after implement‐
ing the SUT. This practice is typical in traditional software development pro‐
cesses, such as waterfall (sequential), incremental (multi-waterfall), spiral (risk-
oriented multi-waterfall), or Rational Unified Process (RUP).
Another relevant testing methodology is Behavior-Driven Development (BDD). BDD
is a testing practice derived from TDD, and consequently, we design tests at the early
stages of the software development lifecycle in BDD. To that aim, conversations occur
between the final user and the development team (typically with the project leader,
manager, or analysts). These conversations formalize a common understanding of the
desired behavior and the software system. As a result, we create acceptance tests in
terms of one or more scenarios following a Given-When-Then structure:
Software Testing Fundamentals | 21
Given
Initial context at the beginning of the scenario
When
Event that triggers the scenario
Then
Expected outcome
TLD is a common practice used to implement Selenium Web‐
Driver. In other words, developers/testers do not implement a
WebDriver test until the SUT is available. Nevertheless, different
methodologies are also possible. For instance, BDD is a common
approach when using WebDriver with Cucumber (see Chapter 9).
Closely related to the domain of testing methodologies, we find the concept of Con‐
tinuous Integration (CI). CI is a software development practice where members of a
software project build, test, and integrate their work continuously. Grady Booch first
coined the term CI in 1991. Now it is a popular strategy to create software.
As Figure 1-7 shows, CI has three separate stages. First, we use a source code reposi‐
tory, a hosting facility to store and share the source code of a software project. We
typically use a version control system (VCS) to manage this repository. A VCS is a tool
that keeps track of the source code, who made each change, and when (sometimes
called patch).
Figure 1-7. CI generic process
22 | Chapter 1: A Primer on Selenium
Git, initially developed by Linus Torvalds, is the preferred VCS today. Other alterna‐
tives are a concurrent versions system (CVS) or Subversion (SVN). On top of Git, sev‐
eral code hosting platforms (such as GitHub, GitLab, or Bitbucket) provide
collaborative cloud repository hosting services for developing, sharing, and maintain‐
ing software.
Developers synchronize a local repository (or simply, repo) copy in their local envi‐
ronments. Then, they do the coding work using that local copy, committing new
changes to the remote repository (typically daily). The basic idea of CI is that every
commit triggers the build and test of the software with the new changes. The test
suite executed to assess that a patch does not break the build is called a regression test.
A regression suite can contain tests of different types, including unit, integration,
end-to-end, etc.
When the number of tests is too large for regression testing, we typically choose only
a part of the relevant tests from the whole suite. There are different strategies to select
these tests, for instance, smoke testing (i.e., tests that ensure the critical functionality)
or sanity testing (i.e., tests that evaluate the basic functionality). Lastly, we can execute
the complete suite as a scheduled task (typically nightly).
We need to use a server-side infrastructure called a build server to implement a CI
pipeline. The build server usually reports a problem to the original developer when
the regression tests fail. Table 1-8 provides a summary of several build servers.
Table 1-8. Build servers
Name Description License Maintainer Website
Bamboo Easy use with Jira (issue
tracker) and Bitbucket
Commercial Atlassian https://www.atlassian.com/software/bamboo
GitHub
Actions
Integrated build server in
GitHub
Free for public
repositories
Microsoft https://github.com/features/actions
GitLab
CI/CD
Integrated build server in
GitLab
Free for public
repositories
GitLab https://docs.gitlab.com/ee/ci
Jenkins Open source automation
server
MIT Jenkins team https://www.jenkins.io
I use a GitHub repository (https://github.com/bonigarcia/selenium-
webdriver-java) to publish and maintain the test examples presen‐
ted in this book. GitHub Actions is the build server for this repo
(see Chapter 2).
Software Testing Fundamentals | 23
We can extend a typical CI pipeline in two ways (see Figure 1-8):
Continuous Delivery (CD)
After CI, the build server deploys the release to a staging environment (i.e., a rep‐
lica of a production environment for testing purposes) and executes the automa‐
ted acceptance tests (if any).
Continuous Deployment
The build server deploys the software release to the production environment as
the final step.
Figure 1-8. Continuous Integration, Delivery, and Deployment pipeline
Close to CI, the term DevOps (development and operations) has gained momentum.
DevOps is a software methodology that promotes communication and collaboration
between different teams in a software project to develop and deliver software
efficiently. These teams include developers, testers, QA (quality assurance), opera‐
tions (infrastructure), etc.
Test Automation Tools
We need to use some tooling to implement, execute, and control automated tests
effectively. One of the most relevant categories for testing tools is the unit testing
framework. The original framework in the unit testing family (also known as xUnit) is
SmalltalkUnit (or SUnit). SUnit is a unit test framework for the Smalltalk language
created by Kent Beck in 1999. Erich Gamma ported SUnit to Java, creating JUnit.
Since then, JUnit has been very popular, inspiring other unit testing frameworks.
Table 1-9 summarizes the most relevant unit testing frameworks in different
languages.
24 | Chapter 1: A Primer on Selenium
Table 1-9. Unit testing frameworks
Name Language Description License Maintainer Website
JUnit Java Reference implementation of
xUnit family
EPL JUnit team https://junit.org
TestNG Java Inspired by JUnit and NUnit,
including extra features
Apache
2.0
Cedric Beust https://testng.org
Mocha JavaScript Test framework for Node.js and
the browser
MIT OpenJS
Foundation
https://mochajs.org
Jest JavaScript Focused on simplicity with a
focus on web applications
MIT Facebiij https://jestjs.io
Karma JavaScript Allows you to execute JavaScript
tests in web browsers
MIT Karma team https://karma-runner.github.io
NUnit .Net Unit testing framework for
all .Net languages (C#, Visual
Basic, and F#)
MIT .NET
Foundation
https://nunit.org
unittest Python Unit testing framework included
as a standard library as of Python
2.1
PSF
License
Python
Software
Foundation
https://docs.python.org/library/unitt
est.html
minitest Ruby Complete suite of testing utilities
for Ruby
MIT Seattle Ruby
Brigade
https://github.com/settlers/minitest
An important common characteristic of the xUnit family is the test structure, com‐
posed of four phases (see Figure 1-9):
Setup
The test case initializes the SUT to exhibit the expected behavior.
Exercise
The test case interacts with the SUT. As a result, the test gets an outcome from
the SUT.
Verify
The test case decides if the obtained outcome from the SUT is as expected. To
that aim, the test contains one or more assertions. An assertion (or predicate) is a
boolean-value function that checks if an expected condition is true. The execu‐
tion of the assertions generates a test verdict (typically, pass or fail).
Teardown
The test case puts the SUT back into the initial state.
Software Testing Fundamentals | 25
Figure 1-9. Unit test generic structure
We can use unit testing frameworks in conjunction with other
libraries or utilities to implement any test type. For example, as
explained in Chapter 2, we use JUnit and TestNG to embed the call
to the Selenium WebDriver API, implementing end-to-end tests
for web applications.
The stages of setup and teardown are optional in a unit test case. Although it is not
strictly mandatory, verifying is highly recommended. Even if unit testing frameworks
include capabilities to implement assertions, it is common to incorporate third-party
assertions libraries. These libraries aim to improve the test code’s readability by pro‐
viding a rich set of fluent assertions. In addition, these libraries offer enhanced error
messages to help testers understand the cause of a failure. Table 1-10 contains a sum‐
mary of some of the most relevant assertion libraries for Java.
Table 1-10. Assertion libraries for Java
Name Description License Maintainer Website
AssertJ Fluent assertions Java library Apache 2.0 AssertJ team https://assertj.github.io/doc
Hamcrest Java library of matchers aimed to create flexible
assertions
BSD Hamcrest team http://hamcrest.org
Truth Fluent assertions for Java and Android Apache 2.0 Google https://truth.dev
26 | Chapter 1: A Primer on Selenium
As you can see in Figure 1-9, the SUT usually can query another component, named
the Depended-On Component (DOC). In some cases (e.g., at the unit or system testing
level), we might want to isolate the SUT from the DOC(s). We can find a wide variety
of mock libraries to achieve this isolation.
Table 1-11 shows a comprehensive summary of some of these mock libraries for Java.
Table 1-11. Mock libraries for Java
Name Level Description License Maintainer Website
EasyMock Unit It allows mocking objects for unit
testing using Java annotations
Apache EasyMock team https://easymock.org
Mockito Unit Mocking Java library for mock
creation and verification
MIT Mockito team https://site.mockito.org
JMockit Integration It allows out-of-container
integration testing for Java EE and
Spring-based apps
Open JMockit team https://jmockit.github.io
MockServer System Mocking library for any system
integrated via HTTP or HTTPS with
Java clients
Apache
2.0
James Bloom https://www.mock-server.com
WireMock System Tool for simulating HTTP-based
services
Apache
2.0
Tom Akehurst https://wiremock.org
The last category of testing tools we analyze in this section is BDD, a development
process that creates acceptance tests. There are plenty of alternatives to implement
this approach. For instance, Table 1-12 shows a condensed summary of relevant BDD
frameworks.
Table 1-12. BDD frameworks
Name Language Description License Maintainer Website
Cucumber Ruby, Java,
JavaScript,
Python
Testing framework to
created automated
acceptance tests following
a BDD approach
MIT SmartBear
Software
https://cucumber.io
FitNesse Java Standalone collaborative
wiki and acceptance
testing framework
CPL FitNesse team http://fitnesse.org
JBehave Java, Groovy,
Kotlin, Ruby,
Scala
BDD framework for all JVM
languages
BSD-3-
Clause
JBehave team https://jbehave.org
Jasmine JavaScript BDD framework for
JavaScript
MIT Jasmine team https://jasmine.github.io
Capybara Ruby Web-based acceptance
test framework that
simulates scenarios for
user stories
MIT Thomas
Walpole
https://teamcapybara.github.io/ca
pybara
Software Testing Fundamentals | 27
Name Language Description License Maintainer Website
Serenity
BDD
Java,
Javascript
Automated acceptance
testing library
Apache
2.0
Serenity BDD
team
https://serenity-bdd.info
Summary and Outlook
Selenium has come a long way since its inception in 2004. Many practitioners con‐
sider it the de facto standard solution to develop end-to-end tests for web applica‐
tions, and it is used by thousands of projects worldwide. In this chapter, you have
seen the foundations of the Selenium project (made up of WebDriver, Grid, and
IDE). In addition, Selenium has a rich ecosystem and active community. WebDriver
is the heart of the Selenium project, and it is a library that provides an API to control
different web browsers (e.g., Chrome, Firefox, Edge, etc.) programmatically.
Table 1-13 contains a comprehensive overview of the primary and secondary uses of
Selenium WebDriver.
Table 1-13. Selenium WebDriver primary and secondary usages
Primary Secondary (other usages)
Purpose Automated testing Web scraping, web-based administration tasks
Test level End-to-end testing System testing (mocking backend calls)
Acceptance testing (e.g., using with Cucumber)
Test type Functional testing (ensuring expected behavior)
Cross-browser testing (compatibility in different
web browsers)
Regression testing (ensuring build after each
commit in CI)
Nonfunctional testing (e.g., load, security,
accessibility, or localization)
Test methodology TLD (implementing tests when SUT is available) BDD (defining user scenarios at early development
stages)
In the next chapter, you discover how to set up a Java project using Maven or Gradle
as build tools. This project will contain end-to-end tests for web applications using
JUnit and TestNG as the unit testing frameworks and calls to the Selenium Web‐
Driver API. In addition, you will learn how to control different web browsers (e.g.,
Chrome, Firefox, or Edge) with a basic test case (the Selenium WebDriver’s version of
the classic hello world).
28 | Chapter 1: A Primer on Selenium
Another Random Document on
Scribd Without Any Related Topics
Handson Selenium Webdriver With Java A Deep Dive Into The Development Of Endtoend Tests 1st Edition Boni Garcia
Handson Selenium Webdriver With Java A Deep Dive Into The Development Of Endtoend Tests 1st Edition Boni Garcia
Handson Selenium Webdriver With Java A Deep Dive Into The Development Of Endtoend Tests 1st Edition Boni Garcia
The Project Gutenberg eBook of Pagan Origin
of Partialist Doctrines
This ebook is for the use of anyone anywhere in the United
States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it away
or re-use it under the terms of the Project Gutenberg License
included with this ebook or online at www.gutenberg.org. If you
are not located in the United States, you will have to check the
laws of the country where you are located before using this
eBook.
Title: Pagan Origin of Partialist Doctrines
Author: John Claudius Pitrat
Release date: September 3, 2013 [eBook #43630]
Most recently updated: October 23, 2024
Language: English
Credits: E-text prepared by Carlos Colon, Princeton Theological
Seminary Library, and the Online Distributed
Proofreading Team (http://www.pgdp.net) from page
images generously made available by Internet Archive
(http://archive.org)
*** START OF THE PROJECT GUTENBERG EBOOK PAGAN ORIGIN
OF PARTIALIST DOCTRINES ***
The Project Gutenberg eBook, Pagan Origin of Partialist Doctrines,
by John Claudius Pitrat
Note: Images of the original pages are available through Internet
Archive. See http://archive.org/details/paganoriginofp00pitr
PAGAN ORIGIN
OF
PARTIALIST DOCTRINES.
BY
REV. JOHN CLAUDIUS PITRAT,
a member of the university of france; author of "jesuits unveiled," of "paul
and julia," etc., and formerly a romish priest.
PUBLISHED BY THE AUTHOR.
CINCINNATI:
LONGLEY BROTHERS, PRINTERS
168 VINE ST., ABOVE FOURTH.
1857.
Entered according to act of Congress, in the year 1857, by
JOHN CLAUDIUS PITRAT,
In the Clerk's Office of the District Court for the Southern District of
Ohio.
To Brother John A. Gurley.
Dear Friend Gurley,—To you, who have fed me when I was starving,
sheltered me when I was a homeless exile, and befriended me when
I was forlorn, and my life was sought by my persecutors, this
volume I inscribe, as a feeble token of my lasting gratitude and
friendship.
J. C. Pitrat.
Handson Selenium Webdriver With Java A Deep Dive Into The Development Of Endtoend Tests 1st Edition Boni Garcia
PREFACE.
Two arguments can be brought forth to prove that the Partialist
doctrines are not taught in the Scriptures: the one is drawn from the
Scriptures themselves, and the other is drawn from history.
The first argument, drawn from the Scriptures, is this:
The Partialist doctrines are not taught in the Scriptures, if it can be
proved by the Scriptures themselves that the Partialist doctrines are
not contained therein. But it can be proved by the Scriptures
themselves that the Partialist doctrines are not contained therein.
Then the Partialist doctrines are not taught in the Scriptures.
The second argument, drawn from history, is this:
The Partialist doctrines are not taught in the Scriptures, if it can be
proved by history, that the origin of the Partialist doctrines is Pagan.
But it can be proved by history that the origin of the Partialist
doctrines is Pagan. Then the Partialist doctrines are not taught in the
Scriptures.
These two arguments, as he who reflects can easily perceive, not
only corroborate each other, but their respective proving force is
such, that, if considered separately, each one is sufficient to
peremptorily prove that the Partialist doctrines are not taught in the
Scriptures. The former, till now, we Universalists have exclusively
used, and it has been efficacious in causing the scales of early and
strong prejudices to fall from the eyes of thousands. However, it is
unfortunately a fact, confirmed by daily experience, that the
conclusions arrived at through scriptural controversies are striking
only to minds of a particular bent and culture. On the contrary, the
conclusions arrived at through historical facts present themselves to
the mind of all, clear, vivid and irresistible. It is for this reason that
the author, in this book, presents to the consideration of the
Universalist denomination, and of the public in general, the second
argument, drawn from history. The vast number of historical facts, of
quotations, extracts, etc., contained in this volume, have been
translated from many languages, with as much accuracy as possible.
May God bless this work, intended to confirm the Universalists in
their beloved faith; and also to break the chain of prejudice which
keeps millions of men in ignorance, in superstition, in perpetual fear,
and thereby in spiritual bondage: "Ye shall know the truth, and the
truth shall make you free."
THE AUTHOR.
Handson Selenium Webdriver With Java A Deep Dive Into The Development Of Endtoend Tests 1st Edition Boni Garcia
CONTENTS.
Dedication. iii
Preface. v
CHAPTER I.
True Spirit of Pagan Religions. 9
CHAPTER II.
Pagan Origin of Mysteries. 28
CHAPTER III.
Pagan Origin of the Doctrine of a Personal Devil. 58
CHAPTER IV.
Pagan Origin of the Doctrine of Original Sin. 68
CHAPTER V.
Pagan Origin of the Doctrine of Trinity. 80
CHAPTER VI.
Pagan Origin of the Doctrine of the Supreme Divinity of Jesus
Christ. 87
CHAPTER VII.
Pagan Origin of the Doctrine of Endless Hell. 111
Article I.—Metempsychosis or Transmigration of the
Souls. 111
Article II.—Tartarus. 129
Article III.—Did the Christians of the First Centuries
believe in Endless Hell. 136
Article IV.—How the Church of Rome borrowed the
doctrine of Endless Hell from the Pagans; and how,
afterwards, the self-called Orthodox Protestant
Churches borrowed it from the Church of Rome. 170
CHAPTER VIII.
Pagan Origin of the Doctrine of a First Judgment, by Jesus
Christ, immediately after the Separation of the Soul from the
Body. 182
CHAPTER IX.
Pagan Origin of the Doctrine of the Resurrection of the Body. 190
CHAPTER X.
Pagan Origin of the Doctrine of a General Judgment at the end
of the World. 205
CHAPTER XI.
Pagan Origin of the Doctrine of Vicarious Atonement. 229
Valedictory. 246
PAGAN ORIGIN
OF
PARTIALIST DOCTRINES.
CHAPTER I.
TRUE SPIRIT OF PAGAN RELIGIONS.
It seems to be an undeniable fact, that, before the coming of Jesus
Christ, nations had immemorially and universally believed, that the
universe, or nature, was an uncreated but animated being, whose
vast body comprised the earth, the sun, the planets and the stars, to
which one great soul impressed motion and life. Also they believed
that all those principal parts, or, in other words, principal members
of the body of the universe, were animated by emanations or
irradiations of the great soul of the universe, or nature. This
Pantheistic doctrine we find recorded by the Chaldean Zoroaster, in
his Zend-Avesta; by the Phœnician Sanchoniaton in his Mythological
History; by the author of the Indian Vedam; and by the Chinese
Confucius, in his Theology. Weighty is the testimony of those
authors, who lived, Confucius perhaps excepted, at about the time
of Moses. Also, the above doctrine they themselves believed and
taught. More, we find the same testimony, the same doctrine, and
the same teaching, in nearly all the works of the celebrated poets,
orators and philosophers of posterior ages.
Pliny, the historian and naturalist, writes: "The world, or what we call
the heaven, which, in its vast embrace, encircles all beings, is a God
eternal, immense, uncreated and immortal. To seek any thing
beyond it is beyond man's reach, and is vain labor. Behold, the
universe is the Being truly sacred, the Being eternal, immense,
comprising all in himself: he is all in all, or rather he is himself all. He
is the work of nature, and nature itself."
We read in the sixth book of Eneida, by Virgil: "Know, O my son!
that the heavens and the earth, the deep, the bright globe of the
moon, and all stars are moved by a principle of inly life, which
perpetuates its existence; that it is a great intelligent soul, extending
to all the parts of the vast body of the universe; and which,
connected with all, impresses to all an eternal movement. This soul
is the source of the life of man, of that of flocks, birds, and of all the
monsters of the deep. The bright force that animates them
emanates from that eternal fire that shines in the sky, and which, a
captive in the gross matter of bodies, develops itself only as
permitted by the divers mortal organizations that blunt its force and
activity. At the death of each animal those germs of particular life
return to their source, and to the principle of life that circulates in
the starry sphere."
This belief led men to the worship of the universe, or nature, and
became the basis of their mythology. They adored the vast body of
nature, and its great soul, under the name of Supreme Being, of
Jupiter, of Vichnou, of Pan, etc. They adored the earth, the sun, the
planets and the stars under other names. They erected temples,
altars, statues and chapels to those deities, and worshiped them—
not the wood, stone, or marble, as they are unjustly accused of, but
the emanations of the great soul of the universe, which animated all
those principal members of the vast body of nature, whose might
and influence impressed them with wonder, terror or gratitude, and
thus attracted their adoration.
The Chinese adored the heavens under the name of great Tien. The
Supreme Being in the Chou-King is designated by the name of Tien,
which means from heaven, and of Chang-Tien, supreme heaven.
They had reared temples to the sun, to the moon, and to the stars;
and also one to the great being formed of the sky, of the earth and
of the elements,—being which is the universe named by them Tay-ki.
They worshiped the heavens at the time of the two solstices. The
Japanese adored the stars and planets which they supposed to be
animated by geniuses or gods. They had a temple dedicated to the
splendor of the sun. They celebrated the feast of the moon on the
7th of September, and spent the whole night in rejoicing by her light.
The Chinese and the Japanese practice the same worship even in
our days.
The Egyptians adored the sun under the name of Osiris, and the
moon under the name of Iris. To them both they ascribed the
government of the world. They built, to honor Osiris, the City of the
Sun, or Heliopolis, and also a splendid temple in which they placed
his statue. They worshiped all the stars and planets which compose
the Zodiac. The animals consecrated in the Egyptian temples, and
religiously revered, represented the various functions of the supreme
cause; and they referred to the sky, to the sun, to the moon, and to
the constellations.
The Phœnicians worshiped the moon and the stars. They adored the
sun under the name of Hercules. The Ethiopians adored the sun and
the moon; and Diodorus informs us, that those of their tribes who
inhabited the country above Meroe adored the sun, the moon, and
the universe. They called themselves the sons of the sun: Persina
was the priestess of the moon, and the king, her husband, was the
priest of the sun. All the Africans who were settled along the coast
of Angola, and of Congo, worshiped the sun and the moon; so the
inhabitants of the island of Teneriffe did. The oldest worship of the
Arabs was Sabism, the religion universally spread in the Orient: the
heaven and the stars were objects of veneration. The moon was
more especially adored. The Saracens called her Cabar, which means
great: even now-a-days her crescent adorns the religious
monuments of the Turks. Among the Arabs each tribe was under the
invocation or patronage of a star.
The Sabism was also the religion of the ancient Chaldeans. Even
now there is at Helle, on the ruins of Babylon, a mosque named
Meshed Eschams, or Mosque of the Sun. In this city was the temple
of Belus, or of the sun, the great deity of the Babylonians. To this
same god the Persians reared temples and consecrated images,
under the name of Mithra. They also honored the heaven under the
name of Jupiter, the moon and Venus, the fire, the earth, the air or
wind, and water. The fire ether that circulates in the whole universe,
and of which the sun is the main force, was represented in the
Pyrees by the sacred fire kept incessantly burning by the wizards, or
priests. At Tymbree, in Troades, the sun was adored under the name
of Apollo. The island of Rhodes was consecrated to the sun, to
whom the colossal statue, known under the name of the Colossus of
Rhodes, was erected. The Massagetes, the Abasges, the Derbises,
the Tartars, the Moscanians, the Tchouvaches, the Toungouses, the
Huns, all the Scytic nations, the Iberians, the Albanians, the
Colchidians, the Phrygians, and the Laodiceans, worshiped the earth,
the sun, the moon, and the stars, under various emblems.
Plato informs us that the ancient Greeks had no other gods than the
sun, the moon, the earth, the stars, water, and fire. Orpheus
considered the sun as the greatest of the gods, and adored him
upon mounts at his rise. Epicharmis, disciple of Pythagoras, called
gods the sun, the moon, the stars, the earth, water and fire.
Agamemnon, in Homer, sacrificed to the sun and to the earth. The
choir, in the Œdipus of Sophocles, invokes the sun as being the first
among the gods, and their chief. The earth was worshiped in the
island of Cos. Also the earth had a temple at Athens and at Sparta;
and an altar and oracle at Olympia.
When we read Pausanias, who has described Greece and her
religious monuments, we find everywhere traces of the worship of
nature. We see temples, altars, and statues, consecrated to the sun,
to the moon, to the earth, to the Pleiades, to the celestial auriga, to
the goat, to the bear, or Calisto, to the night, to rivers, etc. The
inhabitants of Megalopolis sacrificed to the wind Boreas, and had
planted a grove in his honor. The Macedonians adored Estia, or fire,
and prayed to Bedy, or water. Alexander, king of Macedonia,
sacrificed to the sun, to the moon, and to the earth. The oracle of
Dodone, in all its answers, ordered sacrifices to the Achelous river.
Homer gave the epithet of sacred to the waters of the Alpheus.
Nestor and the Pylians sacrificed a bull to the same river. Achilles let
his hair grow in honor of Sphercius; he also invoked the wind Boreas
and the Zephyrus.
Rivers were reputed as being sacred and divine, because of their
utility to vegetation, to animals, and to commerce; and because
nations considered water as one of the first principles of nature, and
one of the most efficacious agents of the universal life of the Great-
Being in which they believed. In Thessalia a sacred crow was fed in
honor of the sun. This bird is seen yet on the monuments of Mithra,
in Persia. The temples of old Byzantium were consecrated to the
sun, to the moon, and to Venus. Their idols represented them; also
the star Arcture, and the twelve signs of the Zodiac. Rome and Italy
had also a vast number of monuments of worship addressed to
nature, and to its principal agents. Tatius, coming to Rome to share
the sceptre of Romulus, erected altars and temples to the sun, to
the moon, to Saturn, to light, and to fire. The undying fire, or Vesta,
was the most ancient object of worship of the Romans; virgins had
the care to perpetuate it in the temple of this Goddess, as the
wizards did in their Pyrees. "It was," Jornandes said, "an image of
the eternal lights which shine in the heavens."
In Rome there was a famous temple called Tellus, or of the earth, in
which the senate often met. The earth was called mother, because it
was considered as a deity as well as the manes. There was in the
Latium a fountain of the sun, and, near it, two altars upon which
Æneas, when landing in Italy, sacrificed. Romulus established the
games of the circus to honor both the sun, who in his course
measures the year, and the four elements which he modifies by his
mighty influence. Aurelian built at Rome the temple of the sun, and
decked it with gold and precious stones. Augustus, before Aurelian,
had ordered the images of the sun and of the moon to be brought
from Egypt, in order to adorn his triumph over Anthony and
Cleopatra. The moon had a temple on the mount Aventine.
In Sicily oxen were consecrated to the sun; and the island itself was
called the Island of the Sun. The oxen which the companions of
Ulysse ate when they landed, were consecrated to this god. The
citizens of Assora adored the Chrysas river, that bathed their walls.
At Enguyum the people revered the mother-goddesses, the same
deities honored in Crete; namely, the major and minor Ursas. In
Spain the people of Betic had built a temple to the morning star. The
Accitans had erected to the god Sun, under the name of Mars, a
statue whose head imitated the rays of the sun. At Cadix the sun
was also adored, under the name of Hercules. All the nations of
northern Europe, called Celtes, worshiped fire, water, the air, the
sun, the moon, the stars, the trees, and the springs. The conqueror
of Gaul, Cæsar, writes that the Germans immemorially adored the
visible cause, and its principal agents, the sun, the moon, fire or
Vulcain, and the earth, under the name of Herta. Near Narbonne, a
city of Gaul, a temple was dedicated to the wind Circius which
purified the atmosphere. At Toulouse there was a temple of the sun.
The Franks professed the same religion.
In America the Incas of Peru called themselves the sons of the sun:
they dedicated temples and altars to this god, and had instituted
feasts in his honor. The moon was associated to his worship, and
was considered as the mother of all the sublunar productions; and
as the spouse and sister of the sun. In Peru, the star Venus was
adored, and also the meteors, the thunder, and Iris, or rainbow.
Virgins had the care of keeping alive the perpetual fire. In Mexico
the same religion existed. The inhabitants of the Isthmus of Panama,
of Brazil, of Florida; the Indians of the coast of Cumana, the
Floridians, Virginians, and the Canadians believed that there was a
god in the heavens, and that this god was the sun, the spouse of the
moon. They worshiped them as the two supreme causes which ruled
the world.
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.
More than just a book-buying platform, we strive to be a bridge
connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.
Join us on a journey of knowledge exploration, passion nurturing, and
personal growth every day!
ebookbell.com

More Related Content

Similar to Handson Selenium Webdriver With Java A Deep Dive Into The Development Of Endtoend Tests 1st Edition Boni Garcia (20)

PDF
Selenium python
Firdos jahan
 
PPTX
Selenium Basics and Overview topics.pptx
sountharyaravi010
 
PPTX
Selenium Basics and Overview1233444.pptx
sountharyaravi010
 
PDF
How To Use Selenium Successfully (Java Edition)
Dave Haeffner
 
PDF
Gundecha U. - Selenium Testing Tools Cookbook - 2012.pdf
TarunKumar893717
 
PDF
Web driver selenium simplified
Vikas Singh
 
PDF
Selenium Tips & Tricks, presented at the Tel Aviv Selenium Meetup
Dave Haeffner
 
PPTX
Selenium Automation
Anuradha Malalasena
 
PDF
How to use selenium successfully
TEST Huddle
 
PDF
How To Use Selenium Successfully (Java Edition)
Sauce Labs
 
PDF
Selenium -Test automation for web applications
AnisGhelissi
 
PDF
Selenium Automation Testing - A Complete Guide.pdf
kalichargn70th171
 
PPTX
A Deep Dive into the W3C WebDriver Specification
Peter Thomas
 
PDF
Selenium Automation Testing - A Complete Guide
Abhay Kumar
 
PDF
Selenium Automation Testing - A Complete Guide.pdf
flufftailshop
 
PPTX
Test automation using selenium
Cynoteck Technology Solutions Private Limited
 
PPTX
Selenium WebDriver
Yuriy Bezgachnyuk
 
PDF
Selenium course training institute ameerpet hyderabad – Best software trainin...
Sathya Technologies
 
PDF
Selenium course training institute ameerpet hyderabad
Sathya Technologies
 
PDF
Browser-level testing
Martin Kleppmann
 
Selenium python
Firdos jahan
 
Selenium Basics and Overview topics.pptx
sountharyaravi010
 
Selenium Basics and Overview1233444.pptx
sountharyaravi010
 
How To Use Selenium Successfully (Java Edition)
Dave Haeffner
 
Gundecha U. - Selenium Testing Tools Cookbook - 2012.pdf
TarunKumar893717
 
Web driver selenium simplified
Vikas Singh
 
Selenium Tips & Tricks, presented at the Tel Aviv Selenium Meetup
Dave Haeffner
 
Selenium Automation
Anuradha Malalasena
 
How to use selenium successfully
TEST Huddle
 
How To Use Selenium Successfully (Java Edition)
Sauce Labs
 
Selenium -Test automation for web applications
AnisGhelissi
 
Selenium Automation Testing - A Complete Guide.pdf
kalichargn70th171
 
A Deep Dive into the W3C WebDriver Specification
Peter Thomas
 
Selenium Automation Testing - A Complete Guide
Abhay Kumar
 
Selenium Automation Testing - A Complete Guide.pdf
flufftailshop
 
Test automation using selenium
Cynoteck Technology Solutions Private Limited
 
Selenium WebDriver
Yuriy Bezgachnyuk
 
Selenium course training institute ameerpet hyderabad – Best software trainin...
Sathya Technologies
 
Selenium course training institute ameerpet hyderabad
Sathya Technologies
 
Browser-level testing
Martin Kleppmann
 

Recently uploaded (20)

PPTX
Nitrogen rule, ring rule, mc lafferty.pptx
nbisen2001
 
PDF
Introduction presentation of the patentbutler tool
MIPLM
 
PPTX
PPT-Q1-WEEK-3-SCIENCE-ERevised Matatag Grade 3.pptx
reijhongidayawan02
 
PPTX
TRANSLATIONAL AND ROTATIONAL MOTION.pptx
KIPAIZAGABAWA1
 
PPTX
DIGITAL CITIZENSHIP TOPIC TLE 8 MATATAG CURRICULUM
ROBERTAUGUSTINEFRANC
 
PDF
STATEMENT-BY-THE-HON.-MINISTER-FOR-HEALTH-ON-THE-COVID-19-OUTBREAK-AT-UG_revi...
nservice241
 
PDF
Knee Extensor Mechanism Injuries - Orthopedic Radiologic Imaging
Sean M. Fox
 
PDF
The History of Phone Numbers in Stoke Newington by Billy Thomas
History of Stoke Newington
 
PPTX
HUMAN RESOURCE MANAGEMENT: RECRUITMENT, SELECTION, PLACEMENT, DEPLOYMENT, TRA...
PRADEEP ABOTHU
 
PPTX
PPT-Q1-WK-3-ENGLISH Revised Matatag Grade 3.pptx
reijhongidayawan02
 
PPTX
EDUCATIONAL MEDIA/ TEACHING AUDIO VISUAL AIDS
Sonali Gupta
 
PDF
Vani - The Voice of Excellence - Jul 2025 issue
Savipriya Raghavendra
 
PDF
Characteristics, Strengths and Weaknesses of Quantitative Research.pdf
Thelma Villaflores
 
PDF
Governor Josh Stein letter to NC delegation of U.S. House
Mebane Rash
 
PDF
Is Assignment Help Legal in Australia_.pdf
thomas19williams83
 
PDF
Aprendendo Arquitetura Framework Salesforce - Dia 03
Mauricio Alexandre Silva
 
PPTX
How to Manage Allocation Report for Manufacturing Orders in Odoo 18
Celine George
 
PPTX
grade 5 lesson matatag ENGLISH 5_Q1_PPT_WEEK4.pptx
SireQuinn
 
PDF
QNL June Edition hosted by Pragya the official Quiz Club of the University of...
Pragya - UEM Kolkata Quiz Club
 
PDF
Horarios de distribución de agua en julio
pegazohn1978
 
Nitrogen rule, ring rule, mc lafferty.pptx
nbisen2001
 
Introduction presentation of the patentbutler tool
MIPLM
 
PPT-Q1-WEEK-3-SCIENCE-ERevised Matatag Grade 3.pptx
reijhongidayawan02
 
TRANSLATIONAL AND ROTATIONAL MOTION.pptx
KIPAIZAGABAWA1
 
DIGITAL CITIZENSHIP TOPIC TLE 8 MATATAG CURRICULUM
ROBERTAUGUSTINEFRANC
 
STATEMENT-BY-THE-HON.-MINISTER-FOR-HEALTH-ON-THE-COVID-19-OUTBREAK-AT-UG_revi...
nservice241
 
Knee Extensor Mechanism Injuries - Orthopedic Radiologic Imaging
Sean M. Fox
 
The History of Phone Numbers in Stoke Newington by Billy Thomas
History of Stoke Newington
 
HUMAN RESOURCE MANAGEMENT: RECRUITMENT, SELECTION, PLACEMENT, DEPLOYMENT, TRA...
PRADEEP ABOTHU
 
PPT-Q1-WK-3-ENGLISH Revised Matatag Grade 3.pptx
reijhongidayawan02
 
EDUCATIONAL MEDIA/ TEACHING AUDIO VISUAL AIDS
Sonali Gupta
 
Vani - The Voice of Excellence - Jul 2025 issue
Savipriya Raghavendra
 
Characteristics, Strengths and Weaknesses of Quantitative Research.pdf
Thelma Villaflores
 
Governor Josh Stein letter to NC delegation of U.S. House
Mebane Rash
 
Is Assignment Help Legal in Australia_.pdf
thomas19williams83
 
Aprendendo Arquitetura Framework Salesforce - Dia 03
Mauricio Alexandre Silva
 
How to Manage Allocation Report for Manufacturing Orders in Odoo 18
Celine George
 
grade 5 lesson matatag ENGLISH 5_Q1_PPT_WEEK4.pptx
SireQuinn
 
QNL June Edition hosted by Pragya the official Quiz Club of the University of...
Pragya - UEM Kolkata Quiz Club
 
Horarios de distribución de agua en julio
pegazohn1978
 
Ad

Handson Selenium Webdriver With Java A Deep Dive Into The Development Of Endtoend Tests 1st Edition Boni Garcia

  • 1. Handson Selenium Webdriver With Java A Deep Dive Into The Development Of Endtoend Tests 1st Edition Boni Garcia download https://ebookbell.com/product/handson-selenium-webdriver-with- java-a-deep-dive-into-the-development-of-endtoend-tests-1st- edition-boni-garcia-43495464 Explore and download more ebooks at ebookbell.com
  • 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Handson Selenium Webdriver With Java Boni Garca https://ebookbell.com/product/handson-selenium-webdriver-with-java- boni-garca-34883324 Handson Selenium Webdriver With Java Boni Garcia https://ebookbell.com/product/handson-selenium-webdriver-with-java- boni-garcia-62628678 Handson Functional Test Automation With Visual Studio 2017 And Selenium 1st Edition Chaminda Chandrasekara https://ebookbell.com/product/handson-functional-test-automation-with- visual-studio-2017-and-selenium-1st-edition-chaminda- chandrasekara-53001810 Handson Website Scraping With Python Crawling Data Scraping With Beautiful Soup Selenium And More Ona Prado https://ebookbell.com/product/handson-website-scraping-with-python- crawling-data-scraping-with-beautiful-soup-selenium-and-more-ona- prado-58766302
  • 3. Python Web Scraping Handson Data Scraping And Crawling Using Pyqt Selnium Html And Python 2nd Edition 2nd Katharine Jarmul https://ebookbell.com/product/python-web-scraping-handson-data- scraping-and-crawling-using-pyqt-selnium-html-and-python-2nd- edition-2nd-katharine-jarmul-47728702 Handson Systematic Innovation For Business Management First Darrell Mann https://ebookbell.com/product/handson-systematic-innovation-for- business-management-first-darrell-mann-44912938 Handson Ethical Hacking And Network Defense Mindtap Course List 4th Edition Rob Wilson https://ebookbell.com/product/handson-ethical-hacking-and-network- defense-mindtap-course-list-4th-edition-rob-wilson-44975634 Handson Data Analysis With Numpy And Pandas Implement Python Packages From Data Manipulation To Processing 1st Edition Curtis Miller https://ebookbell.com/product/handson-data-analysis-with-numpy-and- pandas-implement-python-packages-from-data-manipulation-to- processing-1st-edition-curtis-miller-45457142 Handson Design Patterns With Kotlin Gof Reactive Patterns Concurrent Patterns And More Alexey Soshin https://ebookbell.com/product/handson-design-patterns-with-kotlin-gof- reactive-patterns-concurrent-patterns-and-more-alexey-soshin-46191644
  • 5. Hands-On Selenium WebDriver with Java A Deep Dive into the Development of End-to-End Tests Boni García Foreword by Simon Stewart C o v e r s S e l e n i u m 4
  • 7. Boni García Hands-On Selenium WebDriver with Java A Deep Dive into the Development of End-to-End Tests Boston Farnham Sebastopol Tokyo Beijing Boston Farnham Sebastopol Tokyo Beijing
  • 8. 978-1-098-11000-0 [LSI] Hands-On Selenium WebDriver with Java by Boni García Copyright © 2022 Boni García. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (https://oreilly.com). For more information, contact our corporate/institu‐ tional sales department: 800-998-9938 or [email protected]. Acquisitions Editor: Suzanne McQuade Development Editor: Rita Fernando Production Editor: Kristen Brown Copyeditor: Piper Editorial Consulting, LLC Proofreader: JM Olejarz Indexer: Sam Arnold-Boyd Interior Designer: David Futato Cover Designer: Karen Montgomery Illustrator: Kate Dullea April 2022: First Edition Revision History for the First Edition 2022-03-31: First Release See https://oreilly.com/catalog/errata.csp?isbn=9781098110000 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Hands-On Selenium WebDriver with Java, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. The views expressed in this work are those of the author and do not represent the publisher’s views. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.
  • 9. To the most precious thing to me in the world: my children, Pablo and Carlos. I love you more than anything.
  • 11. Table of Contents Foreword. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Part I. Introduction 1. A Primer on Selenium. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Selenium Core Components 3 Selenium WebDriver 5 Selenium Grid 6 Selenium IDE 8 Selenium Ecosystem 10 Language Bindings 10 Driver Managers 11 Locator Tools 12 Frameworks 12 Browser Infrastructure 14 Community 15 Software Testing Fundamentals 16 Levels of Testing 16 Types of Testing 19 Testing Methodologies 21 Test Automation Tools 24 Summary and Outlook 28 v
  • 12. 2. Preparing for Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Requirements 29 Java Virtual Machine 30 Text Editor or IDE 30 Browsers and Drivers 30 Build Tools 31 Optional Software 31 Project Setup 32 Project Layout 32 Dependencies 34 Hello World 45 Using Additional Browsers 48 Summary and Outlook 49 Part II. The Selenium WebDriver API 3. WebDriver Fundamentals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Basic WebDriver Usage 53 WebDriver Creation 53 WebDriver Methods 57 Session Identifier 58 WebDriver Disposal 59 Locating WebElements 59 The Document Object Model (DOM) 59 WebElement Methods 61 Location Strategies 62 Finding Locators on a Web Page 72 Compound Locators 74 Relative Locators 76 What Strategy Should You Use? 80 Keyboard Actions 82 File Uploading 83 Range Sliders 84 Mouse Actions 85 Web Navigation 85 Checkboxes and Radio Buttons 86 User Gestures 86 Right-Click and Double-Click 88 Mouseover 89 Drag and Drop 90 vi | Table of Contents
  • 13. Click and Hold 91 Copy and Paste 92 Waiting Strategies 94 Implicit Wait 94 Explicit Wait 96 Fluent Wait 98 Summary and Outlook 100 4. Browser-Agnostic Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Executing JavaScript 101 Synchronous Scripts 102 Pinned Scripts 108 Asynchronous Scripts 109 Timeouts 110 Page Loading Timeout 110 Script Loading Timeout 111 Screenshots 112 WebElement Screenshots 115 Window Size and Position 116 Browser History 117 The Shadow DOM 118 Cookies 120 Dropdown Lists 125 Data List Elements 127 Navigation Targets 128 Tabs and Windows 129 Frames and Iframes 131 Dialog Boxes 133 Alerts, Confirms, and Prompts 134 Modal Windows 136 Web Storage 137 Event Listeners 138 WebDriver Exceptions 142 Summary and Outlook 144 5. Browser-Specific Manipulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Browser Capabilities 145 Headless Browser 147 Page Loading Strategies 151 Device Emulation 153 Web Extensions 155 Table of Contents | vii
  • 14. Geolocation 160 Notifications 162 Browser Binary 165 Web Proxies 166 Log Gathering 168 Get User Media 169 Loading Insecure Pages 171 Localization 173 Incognito 175 Edge in Internet Explorer Mode 175 The Chrome DevTools Protocol 177 CDP Selenium Wrappers 177 CDP Raw Commands 180 Location Context 191 Web Authentication 191 Print Page 193 WebDriver BiDi 194 Summary and Outlook 196 6. Remote WebDriver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Selenium WebDriver Architecture 197 Creation of RemoteWebDriver Objects 199 RemoteWebDriver Constructor 199 RemoteWebDriver Builder 201 WebDriverManager Builder 201 Selenium-Jupiter 202 Selenium Grid 203 Standalone 203 Hub-nodes 207 Fully Distributed 208 Observability 213 Configuration 216 Cloud Providers 217 Browsers in Docker Containers 219 Docker Images for Selenium Grid 220 Selenoid 222 WebDriverManager 224 Selenium-Jupiter 227 Summary and Outlook 228 viii | Table of Contents
  • 15. Part III. Advanced Concepts 7. The Page Object Model (POM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Motivation 231 The POM Design Pattern 232 Page Objects 234 Robust Page Objects 236 Creating a Domain Specific Language (DSL) 240 Page Factory 242 Summary and Outlook 244 8. Testing Framework Specifics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Parameterized Tests 245 Cross-Browser Testing 252 Categorizing and Filtering Tests 256 Ordering Tests 261 Failure Analysis 265 Retrying Tests 273 Parallel Test Execution 278 Test Listeners 282 Disabled Tests 286 Summary and Outlook 289 9. Third-Party Integrations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 File Download 291 Using Browser-Specific Capabilities 292 Using an HTTP Client 294 Capture Network Traffic 296 Nonfunctional Testing 298 Performance 298 Security 303 Accessibility 306 A/B Testing 307 Fluent API 308 Test Data 309 Reporting 312 Behavior Driven Development 316 Web Frameworks 320 Summary and Outlook 322 Table of Contents | ix
  • 16. 10. Beyond Selenium. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 Mobile Apps 325 Mobile Testing 326 Appium 327 REST Services 332 REST Assured 334 Alternatives to Selenium 336 Cypress 336 WebDriverIO 339 TestCafe 340 Puppeteer 341 Playwright 342 Summary and Final Remarks 344 A. What’s New in Selenium 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 B. Driver Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 C. Examples Repository Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 x | Table of Contents
  • 17. Foreword In 1999, Kent Beck wrote Extreme Programming Explained. This introduced the world to Extreme Programming (XP). For many people this was the way they first heard about Agile software development. Over the next 20 years, many of the ideas behind the book faded away, but there was one idea that stuck: we should be writing automated tests that verify our code is working as it should. XP expected these tests to be written before the app logic, leading to Test Driven Development (TDD). Today, while strict TDD is seldom practiced, the idea of writing tests is prevalent (though not always popular!). Most companies now acknowledge the need for some kind of automated testing. Many of us actually write tests! Even “regular” QA roles now frequently require people to write code. In 2004, Jason Huggins started Selenium at a software development consultancy called Thoughtworks, which specialized in Agile development. Employees were stee‐ ped in XP and were keen proponents of TDD. From the very beginning, Selenium has been closely associated with testing. Back then, testing websites in a browser was relatively simple. These were the olden days, when there were dozens of browsers to choose between and JS was still spelled “JavaScript.” Sites were small, functionality limited, and the interactions the user could have via the browser were limited too: maybe just filling out a form and click‐ ing a “submit” button. This is the world that Selenium was born into, and the APIs and functionality it offered were as focused as the platform it tested. Then the world discovered XMLHttpRequest hiding in Internet Explorer, it was implemented in Firefox, and suddenly “Web 2.0” became the hot new buzzword. Google Maps showed the world what browsers could do, and the world loved it! Web‐ sites started offering more functionality, driven by carefully handcrafted JS. Selenium adapted and evolved too. I wrote the WebDriver APIs, and these came to the fore. Although they aimed to lead people in a certain direction, the underlying complexity of what Selenium was trying to automate meant that it became a more complicated tool. xi
  • 18. As I write this, browsers are more capable, powerful, and flexible than ever before. We don’t write “websites” any more. We write “web apps,” the current ultimate expression of that being the “Single Page App” or SPA. These push browsers harder than ever, but they’re a natural evolution. Fortunately, once again, Selenium has evolved and grown to allow these kinds of apps to be automated, adding a range of new features in Selenium 4 to help cope with the new testing needs. Adding this func‐ tionality has made Selenium an even more complicated tool. But despite having grown more complicated over the years, Selenium is a tool used by people of all levels of programming comfort and ability. There’s more to writing a successful Selenium test than “just” learning the APIs. There’s a wealth of technology that surrounds it, from the test frameworks you can use, to the Design Patterns you can (and should!) follow when writing the tests, to how we manage the binary depen‐ dencies required by our tests. If we want our tests to run in a reasonable amount of time, we need to have access to infrastructure that supports this. There’s just so much to learn, and there’s surprisingly little guidance for how all the pieces fit together. That’s why I’m so glad that Boni has written this book. It starts by explaining what Selenium is, and the various components within it, and then each chapter builds on the previous ones, gradually introducing more ideas and concepts in a way that feels natural and obvious. Better yet, Boni goes further than just discussing how to use the raw APIs. He also describes the ecosystem of services, tools, and test runners that people need to under‐ stand to get the most from the tool. His experience using Selenium and providing some of these supporting tools shines through: you’re in the hands of a master here. The way this book is structured allows anyone using Selenium to dive in at the point that feels right to them. Just getting started? Then start at the beginning of the book, as Boni lays out the basics for you in an engaging and approachable way. Maybe you’re familiar with Selenium but want to know what’s new in Selenium 4, or some of the less well-known features it offers? Then just jump into the middle of the book; there’s so much there, even I learned a few things! One thing that I hope people take away from this book is that Selenium is only part of the puzzle that is automated testing. Boni covers this too, introducing readers (you!) to how to integrate it into your test frameworks, to the various unit testing libraries you might want to use, and to Design Patterns that can help keep your tests maintain‐ able and fresh. After all, although it may take time to write an automated test in the first place, it can live for years, and being able to work on it with ease is important. xii | Foreword
  • 19. This book paves the road to mastering Selenium and using it effectively. I sincerely hope that this makes using it easier and—dare I say it?—more enjoyable. — Simon Mavi Stewart Creator of WebDriver, Selenium Project Lead 2009–2021, and coeditor of the W3C WebDriver and WebDriver BiDi specifications London, January 2022 Foreword | xiii
  • 21. Preface Selenium is an open source umbrella project that enables the automation of web browsers. The core component of the Selenium project is Selenium WebDriver, a library for controlling browsers (e.g., Chrome, Firefox, Edge, Safari, or Opera) pro‐ grammatically. Selenium WebDriver provides a cross-browser Application Program‐ ming Interface (API) in several programming languages (officially supported in Java, JavaScript, Python, C#, or Ruby). Although we can use Selenium WebDriver for multiple purposes related to browser automation, its primary use is implementing end-to-end tests for web application verification. Thousands of organizations and testers now use Selenium worldwide, and it is one of the leading solutions for end-to-end testing, supporting a multi- million-dollar industry. Who Should Read This Book This book provides a comprehensive summary of the main features of Selenium WebDriver version 4, using Java as language binding. It reviews the main aspects of automated web navigation, browser manipulation, web element interaction, user impersonation, automated driver management, the Page Object Model (POM) design pattern, use of remote and cloud infrastructure, integration with Docker and third- party tools, and much more. The primary audience of this book includes Java coders of different levels (from beginner to advanced), such as developers, testers, QA engineers, etc. Thus, you need a basic knowledge of the Java language and object-oriented programming. The final goal is to have a comprehensive understanding of the main aspects of Selenium Web‐ Driver to create end-to-end tests in Java using different testing frameworks of your choice (e.g., JUnit or TestNG). xv
  • 22. Why I Wrote This Book Test automation is a software testing technique that leverages automation tools to control test execution. It allows increased efficiency and effectiveness while ensuring the overall quality of a software system. In this arena, Selenium WebDriver is the de facto standard library to develop end-to-end tests for web applications. This book provides the first complete review of Selenium 4 to date. The book follows a learn-by-doing approach. To that aim, we review the main fea‐ tures of Selenium WebDriver through ready-to-be-executed test examples. These examples are publicly available in a GitHub open source repository (https:// github.com/bonigarcia/selenium-webdriver-java). For the sake of completeness, this repository contains each test example in different flavors of the embedding testing framework: JUnit 4, JUnit 5 (alone or with Selenium-Jupiter), and TestNG. Navigating This Book The content of this book is divided into 3 parts and 10 chapters: Part I, Introduction Part I provides technological background on Selenium, test automation, and project setup. This part, more theoretical than practical, is composed of two chapters: • Chapter 1, “A Primer on Selenium”, presents the core components of the Sele‐ nium project (WebDriver, Grid, and IDE) and its ecosystem (i.e., the tools and technologies around Selenium). In addition, this chapter reviews the principles of end-to-end testing related to Selenium. • Chapter 2, “Preparing for Testing”, explains how to set up a Java project (Maven and Gradle) containing end-to-end tests that use the Selenium WebDriver API. Then, you will learn how to develop your first WebDriver tests using different testing frameworks: JUnit 4, JUnit 5 (alone or in conjunction with Selenium- Jupiter), and TestNG. Part II, The Selenium WebDriver API Part II provides practical insight into the Selenium WebDriver API. This part is gui‐ ded by tests available in the examples repository and includes the following chapters: • Chapter 3, “WebDriver Fundamentals”, describes the primary aspects of the Sele‐ nium WebDriver API for carrying out automated interaction with web applica‐ tions. Thus, this chapter reviews several strategies for locating and waiting for web elements. In addition, you will discover how to impersonate user actions (i.e., automated interactions using the keyboard and mouse) in a browser. xvi | Preface
  • 23. • Chapter 4, “Browser-Agnostic Features”, reviews those aspects of the Selenium WebDriver API that are interoperable in different browsers. Hence, this chapter shows how to execute JavaScript, create event listeners, manage windows, make screenshots, handle the shadow DOM, manipulate cookies, access the browser history or web storage, or interact with windows, tabs, and iframes, among other elements. • Chapter 5, “Browser-Specific Manipulation”, explains those aspects of the Sele‐ nium WebDriver API particular to specific browsers. This group of features cov‐ ers browser capabilities (options, arguments, preferences, etc.), the Chrome DevTools Protocol (CDP), geolocation functions, basic and web authentication, printing pages to PDF, or the WebDriver BiDi API. • Chapter 6, “Remote WebDriver”, describes how to use the Selenium WebDriver API to control remote browsers. Then, you will learn how to set up and use Sele‐ nium Grid version 4. Finally, you will discover how to use advanced infrastruc‐ ture for Selenium tests in cloud providers (e.g., Sauce Labs, BrowserStack, or CrossBrowserTesting, among others) and browsers in Docker containers. Part III, Advanced Concepts Part III focuses on leveraging the Selenium WebDriver API in different ambits and use cases. This part includes the following chapters: • Chapter 7, “The Page Object Model (POM)”, introduces POM, a popular design pattern used in conjunction with Selenium WebDriver. This pattern allows users to model web pages using object-oriented classes to ease test maintenance and reduce code duplication. • Chapter 8, “Testing Framework Specifics”, reviews several particular features of the unit testing framework used together with Selenium WebDriver that allow improvements to different aspects of the overall testing process. To that aim, this chapter first explains how to carry out cross-browser testing (i.e., reusing the same test logic for verifying web applications using different browsers) using par‐ ameterized tests and test templates. Then, you will learn how to split tests into different categories for execution filtering, ordering tests, failure analysis (i.e., collecting and analyzing data to determine the cause of a failure), retrying tests, parallel test execution, test listeners, or disabling tests. • Chapter 9, “Third-Party Integrations”, reviews different technologies you can use to enhance your Selenium WebDriver tests, such as reporting tools, test data gen‐ eration, and other frameworks (e.g., Cucumber or Spring). Moreover, this chap‐ ter describes how to use external libraries with Selenium to implement specific use cases, such as file downloading or nonfunctional tests (such as load, security, or accessibility). Preface | xvii
  • 24. • Chapter 10, “Beyond Selenium”, presents a couple of automation frameworks related to Selenium: Appium (for mobile testing) and REST Assured (for testing REST web services). To conclude, we review some of the most relevant current alternatives to Selenium WebDriver, such as Cypress, WebDriverIO, TestCafe, Puppeteer, or Playwright. Conventions Used in This Book The following typographical conventions are used in this book: Italic Indicates new terms, URLs, email addresses, filenames, and file extensions. Constant width Used for program listings, as well as within paragraphs to refer to program ele‐ ments such as variable or function names, databases, data types, environment variables, statements, and keywords. Constant width bold Shows commands or other text that the user should type literally. Constant width italic Shows text that should be replaced with user-supplied values or by values deter‐ mined by context. This element signifies a tip or suggestion. This element signifies a general note. This element indicates a warning or caution. xviii | Preface
  • 25. Using Code Examples Code examples are available for download at https://github.com/bonigarcia/selenium- webdriver-java. If you have a technical question or a problem using the code exam‐ ples, please email [email protected]. This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission. We appreciate, but generally do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Hands-On Selenium WebDriver with Java by Boni García (O’Reilly). Copyright 2022 Boni García, 978-1-098-11000-0.” If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at [email protected]. O’Reilly Online Learning For more than 40 years, O’Reilly Media has provided technol‐ ogy and business training, knowledge, and insight to help companies succeed. Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, visit https://oreilly.com. How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 Preface | xix
  • 26. 800-998-9938 (in the United States or Canada) 707-829-0515 (international or local) 707-829-0104 (fax) We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at https://oreil.ly/handsOn_SeleniumWDJ. Email [email protected] to comment or ask technical questions about this book. For news and information about our books and courses, visit https://oreilly.com. Find us on Facebook: https://facebook.com/oreilly. Follow us on Twitter: https://twitter.com/oreillymedia. Watch us on YouTube: https://www.youtube.com/oreillymedia. Acknowledgments First, I want to thank the team at O’Reilly for making this book a reality. Their edito‐ rial support has been exemplary through every stage of this journey. I also want to recognize the technical reviewers who helped with this book. Their val‐ uable feedback and expert advice improved its quality significantly: Diego Molina (staff software engineer at Sauce Labs and technical lead of the Selenium project), Fil‐ ippo Ricca (associate professor of computer science at Università di Genova), Andrea Stocco (postdoctoral researcher at Software Institute in Università della Svizzera ital‐ iana), Ivan Krutov (software developer at Aerokube), and Daniel Hinojosa (inde‐ pendent consultant, programmer, instructor, speaker, and author)—thank you very much. Lastly, I would like to acknowledge the contribution of Simon Stewart (creator of WebDriver and Selenium project lead until 2021). Thanks a lot, Simon, for writing the foreword on this book and for your priceless feedback about its content. But mainly, I want to recognize your work during all these years leading the Selenium project. Your contributions to the automation testing community are already part of software history. xx | Preface
  • 27. PART I Introduction Selenium is an open source umbrella project composed of three core components: WebDriver, Grid, and IDE. Selenium provides advanced capabilities for browser automation that practitioners typically use for implementing end-to-end tests for web applications. This first part of the book is a comprehensive overview of the Selenium project and its ecosystem. Moreover, it provides a primer on the software testing theory, focusing on its practical applications for Selenium WebDriver. Finally, you will discover how to set up a project (using Maven or Gradle) for developing Web‐ Driver tests. For the sake of completeness, I cover different alternatives regarding the unit testing framework used to embed the calls to the Selenium WebDriver API, namely, JUnit 4, JUnit 5 (alone or extended by Selenium-Jupiter), and TestNG.
  • 29. CHAPTER 1 A Primer on Selenium Selenium is an open source suite composed of a set of libraries and tools that enable the automation of web browsers. We can see Selenium as an umbrella project with three core components: WebDriver, Grid, and IDE (Integrated Development Envi‐ ronment). Selenium WebDriver is a library that allows the driving of browsers pro‐ grammatically. Thus, we can use Selenium WebDriver to navigate websites and interact with web pages (e.g., clicking on links, filling in forms, etc.) as a real user would do, in an automated fashion. The primary use of Selenium WebDriver is the automated testing of web applications. Other Selenium uses include the automation of web-based administration tasks or web scraping (automated web data extraction). This chapter provides a comprehensive overview of the Selenium core components: WebDriver, Grid, and IDE. Then, it reviews the Selenium ecosystem, i.e., other tools and technologies around it. Finally, it analyzes the foundations of software testing related to Selenium. Selenium Core Components Jason Huggins and Paul Hammant created Selenium in 2004 while working in Thoughtworks. They chose the name “Selenium” as a counterpart to Mercury, an existing testing framework developed by Hewlett-Packard. The name is significant because the chemical selenium is known for reducing the toxicity of mercury. That initial version of Selenium (known today as Selenium Core) is a JavaScript library that impersonates user actions in web applications. Selenium Core interprets the so-called Selenese commands to achieve this task. These commands are encoded as an HTML table composed of three parts: command (action executed in a web browser, such as opening a URL or clicking a link), target (locator that identifies a 3
  • 30. web element, such as the attribute of a given component), and value (optional data, such as the text typed into a web-form field). Huggins and Hammant added a scripting layer to Selenium Core in a new project called Selenium Remote Control (RC). Selenium RC follows a client-server architec‐ ture. Clients use a binding language (such as Java or JavaScript) to send Selenese commands over HTTP to an intermediate proxy called the Selenium RC Server. This server launches web browsers on demand, injecting the Selenium Core library into a website and proxying requests from clients to Selenium Core. In addition, the Sele‐ nium RC Server masks the target website to the same local URL of the injected Sele‐ nium Core library to avoid same-origin policy concerns. This approach was a game- changer for browser automation at that time, but it had significant limitations. First, because JavaScript is the underlying technology to support automation, some actions are not permitted since JavaScript does not allow them—for instance, uploading and downloading files or handling pop-ups and dialogs, to name a few. Besides, Selenium RC introduces a relevant overhead that impacts its performance. In parallel, Simon Stewart created the project WebDriver in 2007. WebDriver and Selenium RC were equivalent from a functional perspective, i.e., both projects allow programmers to impersonate web users using a programming language. Neverthe‐ less, WebDriver uses the native support of each browser to carry out the automation, and therefore, its capabilities and performance are far superior to RC. In 2009, after a meeting between Jason Huggins and Simon Stewart at the Google Test Automation Conference, they decided to merge Selenium and WebDriver in a single project. The new project was called Selenium WebDriver or Selenium 2. This new project uses a communication protocol based on HTTP combined with the native automation sup‐ port on the browser. That approach is still the basis of Selenium 3 (released in 2016) and Selenium 4 (released in 2021). Now we refer to Selenium RC and Core as “Sele‐ nium 1,” and its use is discouraged in favor of Selenium WebDriver. This book focu‐ ses on the latest version of Selenium WebDriver to date, i.e., version 4. Appendix A summarizes the novelties shipped with Selenium 4. This appendix also contains a migration guide for bumping from Selenium 3 to 4. Today, Selenium is a well-known automation suite composed of three subprojects: WebDriver, Grid, and IDE. The following subsections present the main characteris‐ tics of each one. 4 | Chapter 1: A Primer on Selenium
  • 31. Selenium WebDriver Selenium WebDriver is a library that allows the controlling of web browsers automat‐ ically. To that aim, it provides a cross-platform API in different language bindings. The official programming languages supported by Selenium WebDriver are Java, JavaScript, Python, Ruby, and C#. Internally, Selenium WebDriver uses the native support implemented by each browser to carry out the automation process. For this reason, we need to place a component called driver between the script using the Sele‐ nium WebDriver API and the browser. Table 1-1 summarizes the browsers and driv‐ ers officially supported by Selenium WebDriver. The name Selenium is widely used to refer to the library for browser automation. Since this term is also the name of the umbrella project, I use Selenium in this book to identify the browser automation suite, which is composed of three compo‐ nents: Selenium WebDriver (library), Selenium Grid (infrastruc‐ ture), and Selenium IDE (tool). Table 1-1. Browsers and drivers supported by Selenium WebDriver Browser Driver Operating system Maintainer Download Chrome/ Chromium chromedriver Windows/ macOS/Linux Google https://chromedriver.chromium.org Edge msedgedriver Windows/ macOS/Linux Microsoft https://developer.microsoft.com/en-us/microsoft-edge/tools/ webdriver Firefox geckodriver Windows/ macOS/Linux Mozilla https://github.com/mozilla/geckodriver Opera operadriver Windows/ macOS/Linux Opera Software AS https://github.com/operasoftware/operachromiumdriver Internet Explorer IEDriverServer Windows Selenium project https://www.selenium.dev/downloads Safari safaridriver macOS Apple Built-in Drivers (e.g., chromedriver, geckodriver, etc.) are platform-dependent binary files that receive commands from a WebDriver script and translate them into some browser-specific language. In the first releases of Selenium WebDriver (i.e., in Sele‐ nium 2), these commands (also known as the Selenium protocol) were JSON messages over HTTP (the so-called JSON Wire Protocol). Nowadays, this communication (still JSON over HTTP) follows a standard specification named W3C WebDriver. This specification is the preferred Selenium protocol as of Selenium 4. Selenium Core Components | 5
  • 32. Figure 1-1 summarizes the basic architecture of Selenium WebDriver we have seen so far. As you can see, this architecture has three tiers. First, we find a script using the Selenium WebDriver API (Java, JavaScript, Python, Ruby, or C#). This script sends W3C WebDriver commands to the second layer, in which we find the drivers. This figure shows the specific case of using chromedriver (to control Chrome) and gecko‐ driver (to control Firefox). Finally, the third layer contains the web browsers. In the case of Chrome, the native browser follows the DevTools Protocol. DevTools is a set of developer tools for browsers based on the Blink rendering engine, such as Chrome, Chromium, Edge, or Opera. The DevTools Protocol is based on JSON-RPC messages and allows inspecting, debugging, and profiling these browsers. In Firefox, the native automation support uses the Marionette protocol. Marionette is a remote protocol based on JSON, allowing instrumenting and controlling web browsers based on the Gecko engine (such as Firefox). Figure 1-1. Selenium WebDriver architecture Overall, Selenium WebDriver allows controlling web browsers as a user would, but programmatically. To that aim, the Selenium WebDriver API provides a wide variety of features to navigate web pages, interact with web elements, or impersonate user actions, among many other capabilities. The target application is web-based, such as static websites, dynamic web applications, Single Page Applications (SPA), complex enterprise systems with a web interface, etc. Selenium Grid The second project of the Selenium family is Selenium Grid. Philippe Hanrigou started the development of this project in 2008. Selenium Grid is a group of net‐ worked hosts that provides browser infrastructure for Selenium WebDriver. This infrastructure enables the (parallel) execution of Selenium WebDriver scripts with remote browsers of a different nature (types and versions) in multiple operating systems. 6 | Chapter 1: A Primer on Selenium
  • 33. Figure 1-2 shows the basic architecture of Selenium Grid. As you can see, a group of nodes provides browsers used by Selenium scripts. These nodes can use different operating systems (as we saw in Table 1-1) with various installed browsers. The cen‐ tral entry point to this Grid is the Hub (also known as Selenium Server). This server- side component keeps track of the nodes and proxies requests from the Selenium scripts. Like in Selenium WebDriver, the W3C WebDriver specification is the stan‐ dard protocol for the communication between these scripts and the Hub. Figure 1-2. Selenium Grid hub-nodes architecture The hub-nodes architecture in Grid has been available since Selenium 2. This archi‐ tecture is also present in Selenium 3 and 4. Nevertheless, this centralized architecture can lead to performance bottlenecks if the number of requests to the Hub is high. Selenium 4 provides a fully distributed flavor of Selenium Grid to avoid this problem. This architecture implements advanced load balancing mechanisms to avoid over‐ loading any component. Chapter 6 describes how to set up Selenium Grid following the classical approach (based on a hub and set of nodes). This chapter also covers the standalone mode (i.e., hub and node(s) hosted in the same machine) and the fully distributed architecture. Selenium Core Components | 7
  • 34. Selenium IDE Selenium IDE is the last core component of the Selenium suite. Shinya Kasatani cre‐ ated this project in 2006. Selenium IDE is a tool that implements the so-called Record and Playback (R&P) automation technique. As the name suggests, this technique has two steps. First, in Selenium IDE, the record part captures user interactions with a browser, encoding these actions as Selenium commands. Second, we use the gener‐ ated Selenium script to execute a browser session automatically (playback). This early version of Selenium IDE was a Firefox plug-in that embedded Selenium Core to record, edit, and play back Selenium scripts. These early versions were XPI modules (i.e., a technology used to create Mozilla extensions). As of version 55 (released in 2017), Firefox migrated support for add-ons to the W3C Browser Exten‐ sion specification. As a result, Selenium IDE was discontinued, and for some time, it has not been possible to use it. The Selenium team rewrote Selenium IDE following the Browser Extensions recommendation to solve this problem. Thanks to this, we can now use Selenium IDE in multiple browsers, such as Chrome, Edge, and Firefox. Figure 1-3 shows the new Selenium IDE GUI (Graphical User Interface). Using this GUI, users can record interactions with a browser and edit and execute the generated script. Selenium IDE encodes each interaction in different parts: a com‐ mand (i.e., the action executed in the browser), a target (i.e., the locator of the web element), and a value (i.e., the data handled). Optionally, we can include a description of the command. Figure 1-3 shows a recorded example of these steps: 1. Open website (https://bonigarcia.dev/selenium-webdriver-java). We will use this website as the practice site in the rest of the book. 2. Click on the link with the text “GitHub.” As a result, the navigation moves to the examples repository source code. 3. Assert that the book title (Hands-On Selenium WebDriver with Java) is present on the web page. 4. Close the browser. 8 | Chapter 1: A Primer on Selenium
  • 35. Figure 1-3. Selenium IDE showing an example of a recorded script Once we have created a script in Selenium IDE, we can export this script as a Sele‐ nium WebDriver test. For instance, Figure 1-4 shows how to convert the presented example as a JUnit test case. Finally, we can save the project on our local machine. The resulting project for this sample is available in the examples GitHub repository. The Selenium project is porting Selenium IDE to Electron at the time of this writing. Electron is an open source framework based on Chromium and Node.js that allows desktop application development. Selenium Core Components | 9
  • 36. Figure 1-4. Exporting a Selenium IDE script to a JUnit test case Selenium Ecosystem Software ecosystems are collections of elements interacting with a shared market underpinned by a common technological background. In the case of Selenium, its ecosystem involves the official core projects and other related projects, libraries, and actors. This section reviews the Selenium ecosystem, divided into the following cate‐ gories: language bindings, driver managers, frameworks, browser infrastructure, and community. Language Bindings As we already know, the Selenium project maintains various language bindings for Selenium WebDriver: Java, JavaScript, Python, Ruby, and C#. Nevertheless, other lan‐ guages are also available. Table 1-2 summarizes these language bindings for Selenium WebDriver maintained by the community. Table 1-2. Unofficial language bindings for Selenium WebDriver Name Language License Maintainer Website hs-webdriver Haskell BSD-3-Clause Adam Curtis https://github.com/kallisti-dev/hs-webdriver php-webdriver PHP MIT Facebook, community https://github.com/php-webdriver/php-webdriver RSelenium R AGPLv3 rOpenSci https://github.com/ropensci/RSelenium 10 | Chapter 1: A Primer on Selenium
  • 37. Name Language License Maintainer Website Selenium Go MIT Miki Tebeka https://github.com/tebeka/selenium Selenium-Remote- Driver Perl Apache 2.0 George S. Baugh https://github.com/teodesian/Selenium-Remote-Driver webdriver.dart Dart Apache 2.0 Google https://github.com/google/webdriver.dart wd JavaScript Apache 2.0 Adam Christian https://github.com/admc/wd Driver Managers Drivers are mandatory components to control web browsers natively with Selenium WebDriver (see Figure 1-1). For this reason, before using the Selenium WebDriver API, we need to manage these drivers. Driver management is the process of down‐ loading, setting up, and maintaining the proper driver for a given browser. The usual steps in the driver management procedure are: 1. Download Each browser has its own driver. For example, we use chromedriver for control‐ ling Chrome or geckodriver for Firefox (see Table 1-1). The driver is a platform- specific binary file. Therefore, we need to download the proper driver for a given operating system (typically, Windows, macOS, or Linux). In addition, we need to consider the driver version since a driver release is compatible with a given browser version (or range). For example, to use Chrome 91.x, we need to download chromedriver 91.0.4472.19. We usually find the browser-driver com‐ pliance in the driver documentation or release notes. 2. Setup Once we have the proper driver, we need to make it available in our Selenium WebDriver script. 3. Maintenance Modern web browsers (e.g., Chrome, Firefox, or Edge) upgrade themselves auto‐ matically and silently, without prompting the user. For this reason, and concern‐ ing Selenium WebDriver, we need to maintain the browser-driver version compatibility in time for these so-called evergreen browsers. As you can see, the driver maintenance process can be time-consuming. Further‐ more, it can cause problems for Selenium WebDriver users (e.g., failed tests due to browser-driver incompatibility after an automatic browser upgrade). For this reason, the so-called driver managers aim to carry out the driver management process in an automated fashion to some extent. Table 1-3 summarizes the available driver manag‐ ers for different language bindings. Selenium Ecosystem | 11
  • 38. Table 1-3. Driver managers for Selenium WebDriver Name Language License Maintainer Website WebDriverManager Java Apache 2.0 Boni García https://github.com/bonigarcia/webdrivermanager webdriver-manager JavaScript MIT Google https://www.npmjs.com/package/webdriver-manager webdriver-manager Python Apache 2.0 Serhii Pirohov https://pypi.org/project/webdriver-manager WebDriverManager.Net C# MIT Aliaksandr Rasolka https://github.com/rosolko/WebDriverManager.Net webdrivers Ruby MIT Titus Fortner https://github.com/titusfortner/webdrivers In this book, I recommend using WebDriverManager because it automates the entire driver maintenance process (i.e., download, setup, and maintenance). See Appendix B for further information about automated and manual driver management. Locator Tools The Selenium WebDriver API provides different ways to locate web elements (see Chapter 3): by attribute (id, name, or class), by link text (complete or partial), by tag name, by CSS (Cascading Style Sheets) selector, or by XML Path Language (XPath). Specific tools can help to identify and generate these locators. Table 1-4 shows some of these tools. Table 1-4. Locators tools summary Name Type License Maintainer Website Chrome DevTools Built-in browser tool Proprietary freeware, based on open source Google https://developer.chrome.com/docs/devtools Firefox Developer Tools Built-in browser tool MPL 2.0 Mozilla https://developer.mozilla.org/en-US/docs/Tools Cropath Browser extension Freeware AutonomIQ https://autonomiq.io/deviq-chropath.html SelectorsHub Browser extension Freeware Sanjay Kumar https://selectorshub.com POM Builder Browser extension Freeware LogiGear Corporation https://pombuilder.com Frameworks In software engineering, a framework is a set of libraries and tools used as a concep‐ tual and technological base and support for software development. Selenium is the foundation for frameworks that wrap, enhance, or complement its default features. Table 1-5 contains some of these frameworks and libraries based on Selenium. 12 | Chapter 1: A Primer on Selenium
  • 39. Table 1-5. Testing frameworks and libraries based on Selenium Name Language Description License Maintainer Website CodeceptJS JavaScript Multi-backend testing framework that models browser interactions as simple steps from a user perspective MIT Michael Bodnarchuk https://codecept.io FluentSelenium Java Fluent API for Selenium WebDriver Apache 2.0 Paul Hammant https://github.com/Selenium HQ/fluent-selenium FluentLenium Java Website and mobile automation framework to create readable and reusable WebDriver tests Apache 2.0 FluentLenium team https://fluentlenium.com Healenium Java Library for improving the stability of Selenium tests by using machine learning algorithms to analyze web and mobile web elements Apache 2.0 Anna Chernyshova and Dmitriy Gumeniuk https://healenium.io Helium Python High-level API based on Selenium WebDriver MIT Michael Herrmann https://github.com/mherrma nn/selenium-python-helium QAF (QMetry Automation Framework) Java Test automation platform for web and mobile applications MIT Chirag Jayswal https://qmetry.github.io/qaf Lightning Java Lightweight Selenium WebDriver client for Java Apache 2.0 FluentLenium https://github.com/aerokube /lightning-java Nerodia Python Python port of the Watir Ruby gem MIT Lucas Tierney https://nerodia.readthedocs.i o Robot Framework Python, Java, .NET, and others Generic automation framework based on human-readable test cases Apache 2.0 Robot Framework Foundation https://robotframework.org Selenide team Java Fluent, concise API for Selenium WebDriver MIT Selenide team https://selenide.org SeleniumBase Python Browser automation framework based on WebDriver and pytest MIT Michael Mintz https://seleniumbase.io Watir (Web Application Testing in Ruby) Ruby Gem library based on WebDriver for automating web browsers MIT Titus Fortner http://watir.com WebDriverIO JavaScript Test automation framework based WebDriver and Appium MIT Christian Bromann https://webdriver.io Nightwatch.js JavaScript Integrated end-to-end testing framework based on the W3C WebDriver MIT Andrei Rusu https://nightwatchjs.org Selenium Ecosystem | 13
  • 40. Name Language Description License Maintainer Website Applitools Java, JavaScript, C#, Ruby, PHP, Python Test automation framework for visual user interface regression and A/B testing. It provides SDKs for Selenium, Appium, and others Commercial Applitools team https://applitools.com Katalon Studio Java, Groovy Test automation platform leveraging Selenium WebDriver, Appium, and cloud providers Commercial Katalon team https://www.katalon.com TestProject Java, C#, Python Test automation platform for web and mobile apps built on top of Selenium and Appium Commercial TestProject team https://testproject.io Browser Infrastructure We can use Selenium WebDriver to control local browsers installed in the machine running the WebDriver script. Also, Selenium WebDriver can drive remote web browsers (i.e., those executed in other hosts). In this case, we can use Selenium Grid to support the remote browser infrastructure. Nevertheless, this infrastructure can be challenging to create and maintain. Alternatively, we can use a cloud provider to outsource the responsibility for support‐ ing the browser infrastructure. In the Selenium ecosystem, a cloud provider is a company or product that supplies managed services for automated testing. These companies typically offer commercial solutions for web and mobile testing. The users of a cloud provider request on-demand browsers of different types, ver‐ sions, and operating systems. Also, these providers typically offer additional services for easing the testing and monitoring activities, such as access to session recordings or analysis capabilities, to name a few. Some of the most relevant cloud providers for Selenium nowadays are Sauce Labs, BrowserStack, LambdaTest, CrossBrowserTest‐ ing, Moon Cloud, TestingBot, Perfecto, or Testinium. Another solution we can use to support the browser infrastructure for Selenium is Docker. Docker is an open source software technology that allows users to pack and run applications as lightweight, portable containers. The Docker platform has two main components: the Docker Engine, a tool for creating and running containers, and the Docker Hub, a cloud service for distributing Docker images. In the Selenium domain, we can use Docker to pack and execute containerized browsers. Table 1-6 presents a summary of relevant projects using Docker in the Selenium ecosystem. 14 | Chapter 1: A Primer on Selenium
  • 41. Table 1-6. Docker resources for Selenium Name Description License Maintainer Website docker- selenium Official Docker images for Selenium Grid Apache 2.0 Selenium project https://github.com/seleniumhq/docker-seleni um Selenoid Lightweight Golang implementation of Selenium Hub running browsers in Docker (images available on Docker Hub) Apache 2.0 Aerokube https://aerokube.com/selenoid Moon Enterprise Selenium cluster that use Docker and Kubernetes Commercial Aerokube https://aerokube.com/moon Callisto Open source Kubernetes-native implementation of Selenium Grid MIT Aerokube https://github.com/wrike/callisto Community Due to its collaborative nature, software development needs the organization and interaction of many participants. In the open source domain, we can measure the success of a project by the relevance of its community. Selenium is supported by a large community of many different participants worldwide. Table 1-7 presents a sum‐ mary of several Selenium resources grouped into the following categories: official documentation, development, support, and events. Table 1-7. Selenium community resources Category Description Website Official documentation User guide https://www.selenium.dev/documentation Blog https://www.selenium.dev/blog Wiki https://github.com/seleniumhq/selenium/wiki Ecosystem https://www.selenium.dev/ecosystem Development Source code https://github.com/seleniumhq/selenium Issues https://github.com/seleniumhq/selenium/issues Governance https://www.selenium.dev/project Support User group https://groups.google.com/group/selenium-users Slack https://seleniumhq.slack.com IRC https://webchat.freenode.net/#selenium StackOverflow https://stackoverflow.com/questions/tagged/selenium Reddit https://www.reddit.com/r/selenium Events Conference https://www.selenium.dev/categories/conference Meetups https://www.meetup.com/topics/selenium Selenium Ecosystem | 15
  • 42. Software Testing Fundamentals Software testing (or simply testing) consists of the dynamic evaluation of a piece of software, called System Under Test (SUT), through a finite set of test cases (or simply tests), giving a verdict about it. Testing implies the execution of SUT using specific input values to assess the outcome or expected behavior. At first glance, we distinguish two separate categories of software testing: manual and automated. On the one hand, in manual testing, a person (typically a software engi‐ neer or the final user) evaluates the SUT. On the other hand, in automated testing, we use specific software tools to develop tests and control their execution against the SUT. Automated tests allow the early detection of defects (usually called bugs) in the SUT while providing a large number of additional benefits (e.g., cost savings, fast feedback, test coverage, or reusability, to name a few). Manual testing can also be a valuable approach in some cases, for example, in exploratory testing (i.e., human test‐ ers freely investigate and evaluate the SUT). There is no universal classification for the numerous forms of test‐ ing presented in this section. These concepts are subject to contin‐ uous evolution and debate, just like software engineering. Consider it a proposal that can fit into a large number of projects. Levels of Testing Depending on the size of the SUT, we can define different levels of testing. These levels define several categories in which software teams divide their testing efforts. In this book, I propose a stacked layout to represent the different levels (see Figure 1-5). The lower levels of this structure represent the tests aimed at verifying small pieces of soft‐ ware (called units). As we ascend in the stack, we find other tiers (e.g., integration, system, etc.) in which the SUT integrates more and more components. Figure 1-5. Stack representation of the different levels of testing 16 | Chapter 1: A Primer on Selenium
  • 43. The lowest level of this stack is unit testing. At this level, we assess individual units of software. A unit is a particular observable element of behavior. For instance, units are typically methods or classes in object-oriented programming and functions in func‐ tional programming. Unit testing aims to verify that each unit behaves as expected. Automated unit tests usually run very fast since each test executes a small amount of code in isolation. To achieve this isolation, we can use test doubles, pieces of software that replace the dependent components of a given unit. For example, a popular type of test double in object-oriented programming is the mock object. A mock object mimics an actual object using some programmed behavior. The next level in Figure 1-5 is integration testing. At this level, different units are com‐ posed to create composite components. Integration testing aims to assess the interac‐ tion between the involved units and expose defects in their interfaces. Then, at the system testing and end-to-end (E2E) levels, we test the software system as a whole. We need to deploy the SUT and verify its high-level features to carry out these levels. The difference between system/end-to-end and integration testing is that the former involves all the system components and the final user (typically imperso‐ nated). In other words, system and end-to-end testing assess the SUT through the User Interface (UI). This UI can be graphical (GUI) or nongraphical (e.g., text-based or other types). The Test Pyramid The test pyramid is a classical representation of the levels of testing. Mike Cohn first coined this concept in 2009. In his original conception, Cohn recommended a large number of unit tests as the basis of testing efforts. The following levels (e.g., integra‐ tion tests) are less numerous in each stage but typically more expensive (in terms of development and maintenance effort) and slow (in terms of execution time). This proposal might be impractical for many projects because unit tests are not always from a comprehensive testing suite. For this reason, other authors define different shapes for the levels of testing, such as the testing trophy (in which the intermediate layer, i.e., the integration test, is the largest). Since the relevance of the different test categories can vary from one project to another, I use a basic stack structure to repre‐ sent the different levels of testing. Figure 1-6 illustrates the difference between system and end-to-end testing. As you can see, on the one hand, end-to-end testing involves the software system and its dependent subsystems (e.g., database or external services). On the other hand, system testing comprises only the software system, and these external dependencies are typi‐ cally mocked. Software Testing Fundamentals | 17
  • 44. Figure 1-6. Component-based representation of the different levels of testing Acceptance testing is the top tier of the presented stack. At this level, the final user par‐ ticipates in the testing process. The objective of acceptance testing is to decide whether the software system meets end-user expectations. As you can see in Figure 1-6, like end-to-end testing, acceptance testing validates the whole system and its dependencies. Therefore, acceptance tests also use the UI to carry out the SUT validation. The primary purpose of Selenium WebDriver is to implement end- to-end tests. Nevertheless, we can use WebDriver to carry out sys‐ tem testing when mocking the backend calls made by the website under test. Moreover, we can use Selenium WebDriver in conjunc‐ tion with a Behavior-Driven Development (BDD) tool to imple‐ ment acceptance tests (see Chapter 9). 18 | Chapter 1: A Primer on Selenium
  • 45. Verification and Validation The down levels of the test stack we have seen (unit, integration, system, and end-to- end testing) belong to development testing. Development testing is a process carried out by the team that produces the software system (i.e., developers, testers, etc.) dur‐ ing the construction phase of the software development lifecycle. Development test‐ ing is a type of verification since we assess that the software meets its stated functional and nonfunctional requirements (i.e., its specification). Using the classical definition stated by Barry Boehm in 1984, verification allows answering the following question: “Are we building the product right?” The top level of the test stack represented in Figure 1-5 (i.e., acceptance testing) belongs to user testing since it involves the final user in the testing process. Accept‐ ance testing is a type of validation because its objective is to prove the software system meets end-user expectations. Validation is a more general process than verification since the system specification does not always reflect the user’s real wishes or needs. Thus, according to Boehm, validation allows answering the question “Are we building the right product?” Types of Testing Depending on the strategy for designing test cases, we can implement different types of tests. The two principal types of testing are: Functional testing (also known as behavioral or closed-box testing) Evaluates the compliance of a piece of software with the expected behavior (i.e., its functional requirements). Structural testing (also known as clear-box testing) Determines if the program-code structure is faulty. To that aim, testers should know the internal logic of a piece of software. The difference between these testing types is that functional tests are responsibility- based, while structural tests are implementation-based. Both types can be performed at any test level (unit, integration, system, end-to-end, or acceptance). Nevertheless, structural tests are commonly done at the unit or integration level since these levels enable more direct control of the code execution flow. Black-box and white-box testing are other names for functional and structural testing, respectively. Nevertheless, these designations are not recommended since the tech industry is trying to adopt more inclusive terms and use neutral terminology instead of potentially harmful language. Software Testing Fundamentals | 19
  • 46. There are different flavors of functional testing. For example: UI testing (known as GUI testing when the UI is graphical) Evaluates if the visual elements of an application meet the expected functionality. Note that UI testing is different from the system and end-to-end testing levels since the former tests the interface itself, and the latter evaluates the whole sys‐ tem through the UI. Negative testing Evaluates the SUT under unexpected conditions (e.g., expected exceptions). This term is the counterpart of the regular functional testing (sometimes called posi‐ tive testing), in which we assess if the SUT behaves as expected (i.e., its happy path). Cross-browser testing This is specific for web applications. It aims to verify the compatibility of websites and applications in different web browsers (types, versions, or operating systems). A third miscellaneous testing type, nonfunctional testing, includes testing strategies that assess the quality attributes of a software system (i.e., its nonfunctional require‐ ments). Common methods of nonfunctional testing include, but are not limited to: Performance testing Assesses different metrics of software systems, such as response time, stability, reliability, or scalability. The objective of performance testing is not finding bugs but finding system bottlenecks. There are two common subtypes of performance testing: Load testing Increases the usage on the system by simulating multiple concurrent users to verify if it can operate in the defined boundaries. Stress testing Exercises a system beyond its operational capacity to identify the actual lim‐ its at which the system breaks. Security testing Tries to evaluate security concerns, such as confidentiality (disclosure of infor‐ mation protection), authentication (ensuring the user identity), or authorization (determining user rights and privileges), among others. Usability testing Evaluates how user-friendly a software application is. This assessment is also called User eXperience (UX) testing. A subtype of usability testing is: 20 | Chapter 1: A Primer on Selenium
  • 47. A/B testing Compares different variations of the same application to determine which one is more effective for its end users. Accessibility testing Evaluates if a system is usable by people with disabilities. We use Selenium WebDriver primarily to implement functional tests (i.e., interacting with a web application UI to assess the appli‐ cation behavior). It is unlikely to use WebDriver to implement structural tests. In addition, although it is not its principal usage, we can use WebDriver to implement nonfunctional tests, e.g., for load, security, accessibility, or localization (assessment of specific locale settings) testing (see Chapter 9). Testing Methodologies The software development lifecycle is the set of activities, actions, and tasks required to create software systems in software engineering. The moment at which software engi‐ neers design and implement test cases in the overall development lifecycle depends on the specific development process (such as iterative, waterfall, or agile, to name a few). Two of the most relevant testing methodologies are: Test Driven Development (TDD) TDD is a methodology in which we design and implement tests before the actual software design and implementation. At the beginning of the 21st century, TDD became popular with the rise of agile software development methodologies, such as Extreme Programming (XP). In TDD, a developer first writes an (initially failing) automated test for a given feature. Then, the developer creates a piece of code to pass that test. Finally, the developer refactors the code to achieve or improve readability and maintainability. Test Last Development (TLD) TLD is a methodology in which we design and implement tests after implement‐ ing the SUT. This practice is typical in traditional software development pro‐ cesses, such as waterfall (sequential), incremental (multi-waterfall), spiral (risk- oriented multi-waterfall), or Rational Unified Process (RUP). Another relevant testing methodology is Behavior-Driven Development (BDD). BDD is a testing practice derived from TDD, and consequently, we design tests at the early stages of the software development lifecycle in BDD. To that aim, conversations occur between the final user and the development team (typically with the project leader, manager, or analysts). These conversations formalize a common understanding of the desired behavior and the software system. As a result, we create acceptance tests in terms of one or more scenarios following a Given-When-Then structure: Software Testing Fundamentals | 21
  • 48. Given Initial context at the beginning of the scenario When Event that triggers the scenario Then Expected outcome TLD is a common practice used to implement Selenium Web‐ Driver. In other words, developers/testers do not implement a WebDriver test until the SUT is available. Nevertheless, different methodologies are also possible. For instance, BDD is a common approach when using WebDriver with Cucumber (see Chapter 9). Closely related to the domain of testing methodologies, we find the concept of Con‐ tinuous Integration (CI). CI is a software development practice where members of a software project build, test, and integrate their work continuously. Grady Booch first coined the term CI in 1991. Now it is a popular strategy to create software. As Figure 1-7 shows, CI has three separate stages. First, we use a source code reposi‐ tory, a hosting facility to store and share the source code of a software project. We typically use a version control system (VCS) to manage this repository. A VCS is a tool that keeps track of the source code, who made each change, and when (sometimes called patch). Figure 1-7. CI generic process 22 | Chapter 1: A Primer on Selenium
  • 49. Git, initially developed by Linus Torvalds, is the preferred VCS today. Other alterna‐ tives are a concurrent versions system (CVS) or Subversion (SVN). On top of Git, sev‐ eral code hosting platforms (such as GitHub, GitLab, or Bitbucket) provide collaborative cloud repository hosting services for developing, sharing, and maintain‐ ing software. Developers synchronize a local repository (or simply, repo) copy in their local envi‐ ronments. Then, they do the coding work using that local copy, committing new changes to the remote repository (typically daily). The basic idea of CI is that every commit triggers the build and test of the software with the new changes. The test suite executed to assess that a patch does not break the build is called a regression test. A regression suite can contain tests of different types, including unit, integration, end-to-end, etc. When the number of tests is too large for regression testing, we typically choose only a part of the relevant tests from the whole suite. There are different strategies to select these tests, for instance, smoke testing (i.e., tests that ensure the critical functionality) or sanity testing (i.e., tests that evaluate the basic functionality). Lastly, we can execute the complete suite as a scheduled task (typically nightly). We need to use a server-side infrastructure called a build server to implement a CI pipeline. The build server usually reports a problem to the original developer when the regression tests fail. Table 1-8 provides a summary of several build servers. Table 1-8. Build servers Name Description License Maintainer Website Bamboo Easy use with Jira (issue tracker) and Bitbucket Commercial Atlassian https://www.atlassian.com/software/bamboo GitHub Actions Integrated build server in GitHub Free for public repositories Microsoft https://github.com/features/actions GitLab CI/CD Integrated build server in GitLab Free for public repositories GitLab https://docs.gitlab.com/ee/ci Jenkins Open source automation server MIT Jenkins team https://www.jenkins.io I use a GitHub repository (https://github.com/bonigarcia/selenium- webdriver-java) to publish and maintain the test examples presen‐ ted in this book. GitHub Actions is the build server for this repo (see Chapter 2). Software Testing Fundamentals | 23
  • 50. We can extend a typical CI pipeline in two ways (see Figure 1-8): Continuous Delivery (CD) After CI, the build server deploys the release to a staging environment (i.e., a rep‐ lica of a production environment for testing purposes) and executes the automa‐ ted acceptance tests (if any). Continuous Deployment The build server deploys the software release to the production environment as the final step. Figure 1-8. Continuous Integration, Delivery, and Deployment pipeline Close to CI, the term DevOps (development and operations) has gained momentum. DevOps is a software methodology that promotes communication and collaboration between different teams in a software project to develop and deliver software efficiently. These teams include developers, testers, QA (quality assurance), opera‐ tions (infrastructure), etc. Test Automation Tools We need to use some tooling to implement, execute, and control automated tests effectively. One of the most relevant categories for testing tools is the unit testing framework. The original framework in the unit testing family (also known as xUnit) is SmalltalkUnit (or SUnit). SUnit is a unit test framework for the Smalltalk language created by Kent Beck in 1999. Erich Gamma ported SUnit to Java, creating JUnit. Since then, JUnit has been very popular, inspiring other unit testing frameworks. Table 1-9 summarizes the most relevant unit testing frameworks in different languages. 24 | Chapter 1: A Primer on Selenium
  • 51. Table 1-9. Unit testing frameworks Name Language Description License Maintainer Website JUnit Java Reference implementation of xUnit family EPL JUnit team https://junit.org TestNG Java Inspired by JUnit and NUnit, including extra features Apache 2.0 Cedric Beust https://testng.org Mocha JavaScript Test framework for Node.js and the browser MIT OpenJS Foundation https://mochajs.org Jest JavaScript Focused on simplicity with a focus on web applications MIT Facebiij https://jestjs.io Karma JavaScript Allows you to execute JavaScript tests in web browsers MIT Karma team https://karma-runner.github.io NUnit .Net Unit testing framework for all .Net languages (C#, Visual Basic, and F#) MIT .NET Foundation https://nunit.org unittest Python Unit testing framework included as a standard library as of Python 2.1 PSF License Python Software Foundation https://docs.python.org/library/unitt est.html minitest Ruby Complete suite of testing utilities for Ruby MIT Seattle Ruby Brigade https://github.com/settlers/minitest An important common characteristic of the xUnit family is the test structure, com‐ posed of four phases (see Figure 1-9): Setup The test case initializes the SUT to exhibit the expected behavior. Exercise The test case interacts with the SUT. As a result, the test gets an outcome from the SUT. Verify The test case decides if the obtained outcome from the SUT is as expected. To that aim, the test contains one or more assertions. An assertion (or predicate) is a boolean-value function that checks if an expected condition is true. The execu‐ tion of the assertions generates a test verdict (typically, pass or fail). Teardown The test case puts the SUT back into the initial state. Software Testing Fundamentals | 25
  • 52. Figure 1-9. Unit test generic structure We can use unit testing frameworks in conjunction with other libraries or utilities to implement any test type. For example, as explained in Chapter 2, we use JUnit and TestNG to embed the call to the Selenium WebDriver API, implementing end-to-end tests for web applications. The stages of setup and teardown are optional in a unit test case. Although it is not strictly mandatory, verifying is highly recommended. Even if unit testing frameworks include capabilities to implement assertions, it is common to incorporate third-party assertions libraries. These libraries aim to improve the test code’s readability by pro‐ viding a rich set of fluent assertions. In addition, these libraries offer enhanced error messages to help testers understand the cause of a failure. Table 1-10 contains a sum‐ mary of some of the most relevant assertion libraries for Java. Table 1-10. Assertion libraries for Java Name Description License Maintainer Website AssertJ Fluent assertions Java library Apache 2.0 AssertJ team https://assertj.github.io/doc Hamcrest Java library of matchers aimed to create flexible assertions BSD Hamcrest team http://hamcrest.org Truth Fluent assertions for Java and Android Apache 2.0 Google https://truth.dev 26 | Chapter 1: A Primer on Selenium
  • 53. As you can see in Figure 1-9, the SUT usually can query another component, named the Depended-On Component (DOC). In some cases (e.g., at the unit or system testing level), we might want to isolate the SUT from the DOC(s). We can find a wide variety of mock libraries to achieve this isolation. Table 1-11 shows a comprehensive summary of some of these mock libraries for Java. Table 1-11. Mock libraries for Java Name Level Description License Maintainer Website EasyMock Unit It allows mocking objects for unit testing using Java annotations Apache EasyMock team https://easymock.org Mockito Unit Mocking Java library for mock creation and verification MIT Mockito team https://site.mockito.org JMockit Integration It allows out-of-container integration testing for Java EE and Spring-based apps Open JMockit team https://jmockit.github.io MockServer System Mocking library for any system integrated via HTTP or HTTPS with Java clients Apache 2.0 James Bloom https://www.mock-server.com WireMock System Tool for simulating HTTP-based services Apache 2.0 Tom Akehurst https://wiremock.org The last category of testing tools we analyze in this section is BDD, a development process that creates acceptance tests. There are plenty of alternatives to implement this approach. For instance, Table 1-12 shows a condensed summary of relevant BDD frameworks. Table 1-12. BDD frameworks Name Language Description License Maintainer Website Cucumber Ruby, Java, JavaScript, Python Testing framework to created automated acceptance tests following a BDD approach MIT SmartBear Software https://cucumber.io FitNesse Java Standalone collaborative wiki and acceptance testing framework CPL FitNesse team http://fitnesse.org JBehave Java, Groovy, Kotlin, Ruby, Scala BDD framework for all JVM languages BSD-3- Clause JBehave team https://jbehave.org Jasmine JavaScript BDD framework for JavaScript MIT Jasmine team https://jasmine.github.io Capybara Ruby Web-based acceptance test framework that simulates scenarios for user stories MIT Thomas Walpole https://teamcapybara.github.io/ca pybara Software Testing Fundamentals | 27
  • 54. Name Language Description License Maintainer Website Serenity BDD Java, Javascript Automated acceptance testing library Apache 2.0 Serenity BDD team https://serenity-bdd.info Summary and Outlook Selenium has come a long way since its inception in 2004. Many practitioners con‐ sider it the de facto standard solution to develop end-to-end tests for web applica‐ tions, and it is used by thousands of projects worldwide. In this chapter, you have seen the foundations of the Selenium project (made up of WebDriver, Grid, and IDE). In addition, Selenium has a rich ecosystem and active community. WebDriver is the heart of the Selenium project, and it is a library that provides an API to control different web browsers (e.g., Chrome, Firefox, Edge, etc.) programmatically. Table 1-13 contains a comprehensive overview of the primary and secondary uses of Selenium WebDriver. Table 1-13. Selenium WebDriver primary and secondary usages Primary Secondary (other usages) Purpose Automated testing Web scraping, web-based administration tasks Test level End-to-end testing System testing (mocking backend calls) Acceptance testing (e.g., using with Cucumber) Test type Functional testing (ensuring expected behavior) Cross-browser testing (compatibility in different web browsers) Regression testing (ensuring build after each commit in CI) Nonfunctional testing (e.g., load, security, accessibility, or localization) Test methodology TLD (implementing tests when SUT is available) BDD (defining user scenarios at early development stages) In the next chapter, you discover how to set up a Java project using Maven or Gradle as build tools. This project will contain end-to-end tests for web applications using JUnit and TestNG as the unit testing frameworks and calls to the Selenium Web‐ Driver API. In addition, you will learn how to control different web browsers (e.g., Chrome, Firefox, or Edge) with a basic test case (the Selenium WebDriver’s version of the classic hello world). 28 | Chapter 1: A Primer on Selenium
  • 55. Another Random Document on Scribd Without Any Related Topics
  • 59. The Project Gutenberg eBook of Pagan Origin of Partialist Doctrines
  • 60. This ebook is for the use of anyone anywhere in the United States and most other parts of the world at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this ebook or online at www.gutenberg.org. If you are not located in the United States, you will have to check the laws of the country where you are located before using this eBook. Title: Pagan Origin of Partialist Doctrines Author: John Claudius Pitrat Release date: September 3, 2013 [eBook #43630] Most recently updated: October 23, 2024 Language: English Credits: E-text prepared by Carlos Colon, Princeton Theological Seminary Library, and the Online Distributed Proofreading Team (http://www.pgdp.net) from page images generously made available by Internet Archive (http://archive.org) *** START OF THE PROJECT GUTENBERG EBOOK PAGAN ORIGIN OF PARTIALIST DOCTRINES ***
  • 61. The Project Gutenberg eBook, Pagan Origin of Partialist Doctrines, by John Claudius Pitrat Note: Images of the original pages are available through Internet Archive. See http://archive.org/details/paganoriginofp00pitr PAGAN ORIGIN OF PARTIALIST DOCTRINES.
  • 62. BY REV. JOHN CLAUDIUS PITRAT, a member of the university of france; author of "jesuits unveiled," of "paul and julia," etc., and formerly a romish priest. PUBLISHED BY THE AUTHOR. CINCINNATI: LONGLEY BROTHERS, PRINTERS 168 VINE ST., ABOVE FOURTH. 1857.
  • 63. Entered according to act of Congress, in the year 1857, by JOHN CLAUDIUS PITRAT, In the Clerk's Office of the District Court for the Southern District of Ohio.
  • 64. To Brother John A. Gurley. Dear Friend Gurley,—To you, who have fed me when I was starving, sheltered me when I was a homeless exile, and befriended me when I was forlorn, and my life was sought by my persecutors, this volume I inscribe, as a feeble token of my lasting gratitude and friendship. J. C. Pitrat.
  • 66. PREFACE. Two arguments can be brought forth to prove that the Partialist doctrines are not taught in the Scriptures: the one is drawn from the Scriptures themselves, and the other is drawn from history. The first argument, drawn from the Scriptures, is this: The Partialist doctrines are not taught in the Scriptures, if it can be proved by the Scriptures themselves that the Partialist doctrines are not contained therein. But it can be proved by the Scriptures themselves that the Partialist doctrines are not contained therein. Then the Partialist doctrines are not taught in the Scriptures. The second argument, drawn from history, is this: The Partialist doctrines are not taught in the Scriptures, if it can be proved by history, that the origin of the Partialist doctrines is Pagan. But it can be proved by history that the origin of the Partialist doctrines is Pagan. Then the Partialist doctrines are not taught in the Scriptures. These two arguments, as he who reflects can easily perceive, not only corroborate each other, but their respective proving force is such, that, if considered separately, each one is sufficient to peremptorily prove that the Partialist doctrines are not taught in the Scriptures. The former, till now, we Universalists have exclusively
  • 67. used, and it has been efficacious in causing the scales of early and strong prejudices to fall from the eyes of thousands. However, it is unfortunately a fact, confirmed by daily experience, that the conclusions arrived at through scriptural controversies are striking only to minds of a particular bent and culture. On the contrary, the conclusions arrived at through historical facts present themselves to the mind of all, clear, vivid and irresistible. It is for this reason that the author, in this book, presents to the consideration of the Universalist denomination, and of the public in general, the second argument, drawn from history. The vast number of historical facts, of quotations, extracts, etc., contained in this volume, have been translated from many languages, with as much accuracy as possible. May God bless this work, intended to confirm the Universalists in their beloved faith; and also to break the chain of prejudice which keeps millions of men in ignorance, in superstition, in perpetual fear, and thereby in spiritual bondage: "Ye shall know the truth, and the truth shall make you free." THE AUTHOR.
  • 69. CONTENTS. Dedication. iii Preface. v CHAPTER I. True Spirit of Pagan Religions. 9 CHAPTER II. Pagan Origin of Mysteries. 28 CHAPTER III. Pagan Origin of the Doctrine of a Personal Devil. 58 CHAPTER IV. Pagan Origin of the Doctrine of Original Sin. 68 CHAPTER V. Pagan Origin of the Doctrine of Trinity. 80
  • 70. CHAPTER VI. Pagan Origin of the Doctrine of the Supreme Divinity of Jesus Christ. 87 CHAPTER VII. Pagan Origin of the Doctrine of Endless Hell. 111 Article I.—Metempsychosis or Transmigration of the Souls. 111 Article II.—Tartarus. 129 Article III.—Did the Christians of the First Centuries believe in Endless Hell. 136 Article IV.—How the Church of Rome borrowed the doctrine of Endless Hell from the Pagans; and how, afterwards, the self-called Orthodox Protestant Churches borrowed it from the Church of Rome. 170 CHAPTER VIII. Pagan Origin of the Doctrine of a First Judgment, by Jesus Christ, immediately after the Separation of the Soul from the Body. 182 CHAPTER IX. Pagan Origin of the Doctrine of the Resurrection of the Body. 190 CHAPTER X. Pagan Origin of the Doctrine of a General Judgment at the end of the World. 205
  • 71. CHAPTER XI. Pagan Origin of the Doctrine of Vicarious Atonement. 229 Valedictory. 246
  • 73. CHAPTER I. TRUE SPIRIT OF PAGAN RELIGIONS. It seems to be an undeniable fact, that, before the coming of Jesus Christ, nations had immemorially and universally believed, that the universe, or nature, was an uncreated but animated being, whose vast body comprised the earth, the sun, the planets and the stars, to which one great soul impressed motion and life. Also they believed that all those principal parts, or, in other words, principal members of the body of the universe, were animated by emanations or irradiations of the great soul of the universe, or nature. This Pantheistic doctrine we find recorded by the Chaldean Zoroaster, in his Zend-Avesta; by the Phœnician Sanchoniaton in his Mythological History; by the author of the Indian Vedam; and by the Chinese Confucius, in his Theology. Weighty is the testimony of those authors, who lived, Confucius perhaps excepted, at about the time of Moses. Also, the above doctrine they themselves believed and taught. More, we find the same testimony, the same doctrine, and the same teaching, in nearly all the works of the celebrated poets, orators and philosophers of posterior ages. Pliny, the historian and naturalist, writes: "The world, or what we call the heaven, which, in its vast embrace, encircles all beings, is a God eternal, immense, uncreated and immortal. To seek any thing
  • 74. beyond it is beyond man's reach, and is vain labor. Behold, the universe is the Being truly sacred, the Being eternal, immense, comprising all in himself: he is all in all, or rather he is himself all. He is the work of nature, and nature itself." We read in the sixth book of Eneida, by Virgil: "Know, O my son! that the heavens and the earth, the deep, the bright globe of the moon, and all stars are moved by a principle of inly life, which perpetuates its existence; that it is a great intelligent soul, extending to all the parts of the vast body of the universe; and which, connected with all, impresses to all an eternal movement. This soul is the source of the life of man, of that of flocks, birds, and of all the monsters of the deep. The bright force that animates them emanates from that eternal fire that shines in the sky, and which, a captive in the gross matter of bodies, develops itself only as permitted by the divers mortal organizations that blunt its force and activity. At the death of each animal those germs of particular life return to their source, and to the principle of life that circulates in the starry sphere." This belief led men to the worship of the universe, or nature, and became the basis of their mythology. They adored the vast body of nature, and its great soul, under the name of Supreme Being, of Jupiter, of Vichnou, of Pan, etc. They adored the earth, the sun, the planets and the stars under other names. They erected temples, altars, statues and chapels to those deities, and worshiped them— not the wood, stone, or marble, as they are unjustly accused of, but the emanations of the great soul of the universe, which animated all those principal members of the vast body of nature, whose might and influence impressed them with wonder, terror or gratitude, and thus attracted their adoration. The Chinese adored the heavens under the name of great Tien. The Supreme Being in the Chou-King is designated by the name of Tien, which means from heaven, and of Chang-Tien, supreme heaven. They had reared temples to the sun, to the moon, and to the stars; and also one to the great being formed of the sky, of the earth and
  • 75. of the elements,—being which is the universe named by them Tay-ki. They worshiped the heavens at the time of the two solstices. The Japanese adored the stars and planets which they supposed to be animated by geniuses or gods. They had a temple dedicated to the splendor of the sun. They celebrated the feast of the moon on the 7th of September, and spent the whole night in rejoicing by her light. The Chinese and the Japanese practice the same worship even in our days. The Egyptians adored the sun under the name of Osiris, and the moon under the name of Iris. To them both they ascribed the government of the world. They built, to honor Osiris, the City of the Sun, or Heliopolis, and also a splendid temple in which they placed his statue. They worshiped all the stars and planets which compose the Zodiac. The animals consecrated in the Egyptian temples, and religiously revered, represented the various functions of the supreme cause; and they referred to the sky, to the sun, to the moon, and to the constellations. The Phœnicians worshiped the moon and the stars. They adored the sun under the name of Hercules. The Ethiopians adored the sun and the moon; and Diodorus informs us, that those of their tribes who inhabited the country above Meroe adored the sun, the moon, and the universe. They called themselves the sons of the sun: Persina was the priestess of the moon, and the king, her husband, was the priest of the sun. All the Africans who were settled along the coast of Angola, and of Congo, worshiped the sun and the moon; so the inhabitants of the island of Teneriffe did. The oldest worship of the Arabs was Sabism, the religion universally spread in the Orient: the heaven and the stars were objects of veneration. The moon was more especially adored. The Saracens called her Cabar, which means great: even now-a-days her crescent adorns the religious monuments of the Turks. Among the Arabs each tribe was under the invocation or patronage of a star. The Sabism was also the religion of the ancient Chaldeans. Even now there is at Helle, on the ruins of Babylon, a mosque named
  • 76. Meshed Eschams, or Mosque of the Sun. In this city was the temple of Belus, or of the sun, the great deity of the Babylonians. To this same god the Persians reared temples and consecrated images, under the name of Mithra. They also honored the heaven under the name of Jupiter, the moon and Venus, the fire, the earth, the air or wind, and water. The fire ether that circulates in the whole universe, and of which the sun is the main force, was represented in the Pyrees by the sacred fire kept incessantly burning by the wizards, or priests. At Tymbree, in Troades, the sun was adored under the name of Apollo. The island of Rhodes was consecrated to the sun, to whom the colossal statue, known under the name of the Colossus of Rhodes, was erected. The Massagetes, the Abasges, the Derbises, the Tartars, the Moscanians, the Tchouvaches, the Toungouses, the Huns, all the Scytic nations, the Iberians, the Albanians, the Colchidians, the Phrygians, and the Laodiceans, worshiped the earth, the sun, the moon, and the stars, under various emblems. Plato informs us that the ancient Greeks had no other gods than the sun, the moon, the earth, the stars, water, and fire. Orpheus considered the sun as the greatest of the gods, and adored him upon mounts at his rise. Epicharmis, disciple of Pythagoras, called gods the sun, the moon, the stars, the earth, water and fire. Agamemnon, in Homer, sacrificed to the sun and to the earth. The choir, in the Œdipus of Sophocles, invokes the sun as being the first among the gods, and their chief. The earth was worshiped in the island of Cos. Also the earth had a temple at Athens and at Sparta; and an altar and oracle at Olympia. When we read Pausanias, who has described Greece and her religious monuments, we find everywhere traces of the worship of nature. We see temples, altars, and statues, consecrated to the sun, to the moon, to the earth, to the Pleiades, to the celestial auriga, to the goat, to the bear, or Calisto, to the night, to rivers, etc. The inhabitants of Megalopolis sacrificed to the wind Boreas, and had planted a grove in his honor. The Macedonians adored Estia, or fire, and prayed to Bedy, or water. Alexander, king of Macedonia,
  • 77. sacrificed to the sun, to the moon, and to the earth. The oracle of Dodone, in all its answers, ordered sacrifices to the Achelous river. Homer gave the epithet of sacred to the waters of the Alpheus. Nestor and the Pylians sacrificed a bull to the same river. Achilles let his hair grow in honor of Sphercius; he also invoked the wind Boreas and the Zephyrus. Rivers were reputed as being sacred and divine, because of their utility to vegetation, to animals, and to commerce; and because nations considered water as one of the first principles of nature, and one of the most efficacious agents of the universal life of the Great- Being in which they believed. In Thessalia a sacred crow was fed in honor of the sun. This bird is seen yet on the monuments of Mithra, in Persia. The temples of old Byzantium were consecrated to the sun, to the moon, and to Venus. Their idols represented them; also the star Arcture, and the twelve signs of the Zodiac. Rome and Italy had also a vast number of monuments of worship addressed to nature, and to its principal agents. Tatius, coming to Rome to share the sceptre of Romulus, erected altars and temples to the sun, to the moon, to Saturn, to light, and to fire. The undying fire, or Vesta, was the most ancient object of worship of the Romans; virgins had the care to perpetuate it in the temple of this Goddess, as the wizards did in their Pyrees. "It was," Jornandes said, "an image of the eternal lights which shine in the heavens." In Rome there was a famous temple called Tellus, or of the earth, in which the senate often met. The earth was called mother, because it was considered as a deity as well as the manes. There was in the Latium a fountain of the sun, and, near it, two altars upon which Æneas, when landing in Italy, sacrificed. Romulus established the games of the circus to honor both the sun, who in his course measures the year, and the four elements which he modifies by his mighty influence. Aurelian built at Rome the temple of the sun, and decked it with gold and precious stones. Augustus, before Aurelian, had ordered the images of the sun and of the moon to be brought
  • 78. from Egypt, in order to adorn his triumph over Anthony and Cleopatra. The moon had a temple on the mount Aventine. In Sicily oxen were consecrated to the sun; and the island itself was called the Island of the Sun. The oxen which the companions of Ulysse ate when they landed, were consecrated to this god. The citizens of Assora adored the Chrysas river, that bathed their walls. At Enguyum the people revered the mother-goddesses, the same deities honored in Crete; namely, the major and minor Ursas. In Spain the people of Betic had built a temple to the morning star. The Accitans had erected to the god Sun, under the name of Mars, a statue whose head imitated the rays of the sun. At Cadix the sun was also adored, under the name of Hercules. All the nations of northern Europe, called Celtes, worshiped fire, water, the air, the sun, the moon, the stars, the trees, and the springs. The conqueror of Gaul, Cæsar, writes that the Germans immemorially adored the visible cause, and its principal agents, the sun, the moon, fire or Vulcain, and the earth, under the name of Herta. Near Narbonne, a city of Gaul, a temple was dedicated to the wind Circius which purified the atmosphere. At Toulouse there was a temple of the sun. The Franks professed the same religion. In America the Incas of Peru called themselves the sons of the sun: they dedicated temples and altars to this god, and had instituted feasts in his honor. The moon was associated to his worship, and was considered as the mother of all the sublunar productions; and as the spouse and sister of the sun. In Peru, the star Venus was adored, and also the meteors, the thunder, and Iris, or rainbow. Virgins had the care of keeping alive the perpetual fire. In Mexico the same religion existed. The inhabitants of the Isthmus of Panama, of Brazil, of Florida; the Indians of the coast of Cumana, the Floridians, Virginians, and the Canadians believed that there was a god in the heavens, and that this god was the sun, the spouse of the moon. They worshiped them as the two supreme causes which ruled the world.
  • 79. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com