Talk description

How is your test automation journey going? You’re working on test automation, yet didn’t receive any proper training? You managed to create some automated tests, but you suspect that something is not quite right with your automation, because your code feels messy, and maintaining it is difficult and very frustrating?

Programmers have tools to handle this, one group of those being called “design patterns”. Four IBM programmers nicknamed the “Gang of Four” first created the term, describing a design pattern as “a description of customized communicating objects and classes that solves a problem in a particular context of software design”. Put more simply: A design pattern is a common way of building things that solves a known problem.

If you’re creating test automation, then you are doing “software design”. Yet a lot of test automation engineers are not aware of (m)any design patterns that could ease their work. This is a pity, because using design patterns has quite some advantages.

Did you know that design patterns

• can speed up the development process by providing tested, proven development paradigms.
• help to prevent hidden subtle issues that often are detected only late in the process.
• improve code readability for people who are familiar with the patterns.
• can help to save costs.

Knowing design patterns provides you with code templates. You don’t need to solve all problems from scratch. Design patterns super-charge object-oriented designs to become more flexible, elegant, and ultimately reusable. They help programmers and test automation engineers reuse successful designs by building new implementations on previous experience. Programmers being familiar with design patterns can immediately apply them to problems without rediscovering them.

In this talk, you will learn

• Specific design patterns for test automation, such as Screenplay & Object Mother Pattern
• The advantages of using design patterns
• The obstacles & hurdles when introducing & using them.
• How to get started applying them in your test automation code & framework.

Disclaimer: This talk is not about any specific tool or framework. The design patterns described are generic, and I’ve seen them work in different contexts.