Page Objects, Builders, and Facades: Key Test Automation Design Patterns Explained
Tip: This is how much money is saved by testing 👈🏻
"And this is probably the most common way when you build UI test automation framework to use Page Object design pattern. Doesn't matter what programming language, what test automation framework. It's just a common thing." - Kostiantyn Teltov
In this episode, I talk with Kostiantyn Teltov about design patterns in test automation. Kosta shows why test code needs the same care as product code. Page Object to cut duplication. Builder to shape data like choosing a burger. Facade as a reception that guides you to the right service. We touch creational patterns and even pools for drivers. DRY, KISS, and YAGNI keep us honest and stop overdesign.
Kostiantyn Teltov was born in Dnipro, Ukraine, and lives in Kraków, Poland, for the past three years.
He has been working in software testing since 2008 and writing code for over 11 years.
His technical background includes C#, Java, JavaScript/TypeScript, and Python, and he can speak four languages — though not all my programming and speaking languages are equally good ;-)
He is a strong advocate of the Shift-Left testing mindset and the Testing Pyramid approach.
He is passionate about mentoring and educating others, especially in Test Automation.
In the past, he has lectured IT courses. Today he speaks at webinars, meetups and perform workshops, and regularly write articles on Medium.
Currently, he works as a QA Lead at Metso, managing five projects and focusing on building QA processes and automation frameworks with limited QA resources.
Test code deserves same engineering standards as product codePage Object pattern reduces duplication in UI testsBuilder pattern simplifies test data setupDRY, KISS, and YAGNI prevent overdesign in automationShare patterns in the team to grow testing skillsMore Links with Insights:
Testwarez