Test Automation Framework (Selenium with Java) — Fear or Code Review and Refactoring (Part 2)

Tomasz Buga
13 min readJan 21, 2022

S01E10 of the Test Automation Framework series about everything you’ll need to set up the nice, simple, yet sophisticated framework.

Covered with clear explanations and pretty illustrations.

Sounds like fun? Cool. Now, please, fasten your seatbelts because you’re here for a ride.

S01E01 — What To Automate?

S01E02 — Test Automation Environment and Tools

S01E03 — The First Selenium Test Case

S01E04 — Selenium Foundations Revisited

S01E05 — Page Factory and Elements Related Exceptions

S01E06 — Page Loading Strategies and Waits

S01E07 — Translating JIRA with Selenide (with Exercises)

S01E08 — JIRA, Selenide, Complex SQL, Java Objects with Equals & HashCode (with Exercises)

S01E09 — Code Review and Refactoring (Part 1)

S01E11 — Allure in Action

I was struggling a lot if should I put the Builder Design Pattern in this Test Automation Framework guide. Ultimately, I’ve come up with a conclusion that it can’t hurt to talk about one of the useful approaches to deal with common issues when we’re talking about Java development.

The idea for the Builder Design Pattern comes from the book Design Patterns written by the so-called Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides). We’re not going to implement exactly the Builder Design proposed in the book, because it wasn’t designed for Test Automation purposes — just the Builder part is enough for us (as in “we don’t need a Director class”).

Why Builder Pattern?

In essence, Builder Pattern allows you to create Immutable Objects which are safer to use because you simply cannot change them. Thus, they’re Thread Safe. Simply put — if something can’t change you don’t have to worry about it.

ColinD wrote:



Tomasz Buga

Software Development Engineer in Tests. Passionate about programming. Experienced, former employee of the insurance industry. Graphic designer by choice.