How are you doing? Have you already created the best test automation framework in the world? 🙂 If you haven’t, I hope today’s post brings you closer to that wishful moment. And what I’m going to discourse today is… patterns. Patterns in test automation.
Whenever I meet with other automation guys, I always try to ask what kind of practices and approaches they apply in their projects. One of such questions is about design patterns in test automation. I’ve got different answers, very interesting answers I’d say. But let’s leave those answers behind and figure out together what are the benefits of using design patterns (yes, you understood correctly, I do believe that makes sense).
First of all, what’s a design pattern from the test automation point of view? I think it’s an approach/solution that makes our life easier: helps to write more understandable and maintainable test code and solves known problems of frameworks architecture. It’s not all about code practices only – some people believe that organizational and process improvement patterns also matter. Okay, they’re important for sure but it’s out of the scope of this post (maybe we’d discuss them later).
I bet that all of you have heard or worked with design patterns before even if you just started dealing with test automation. Am I right? As an example, it’s worth to mention the PageObject pattern that became famous and beloved together with Selenium Webdriver. I think everybody agrees that this pattern simplifies functional test automation of web-applications (if designed properly). However, I’ve seen many examples of incorrect PageObject usage which didn’t help at all but brought mess to automation frameworks.
Other examples like Singleton of Fabric design patterns – we apply them often for cases when we want to build different test layers and/or support tools (like custom report writers, test runners, recorders, etc.). You can find an example of the Fabric pattern usage in my WebDriverManager fabric example for Selenium based frameworks article where I combined several third-party libraries for Selenium Webdriver creation. Frankly speaking, Fabric design pattern is a common fallacy, at least in test automation area. The fact is that Factory pattern is often used (mostly by newbies) without any reason for that. As a result, a test automation framework becomes cumbersome and costly maintainable. Basically, the same makes sense for all patterns, if they’re just applied…
After some time, I decided for myself – it shouldn’t be too much of patterns in the test code (it’s my personal opinion, you might have a different one). An automation framework with many patterns concentrates on the self-development instead of testing goals, brings another level of complexity for those who maintain. An automation framework without patterns at all will become messy and not really easy-to-extend. That’s why I’m trying to apply patterns only when a framework architecture may suffer from its absence. “It’s never too much” principle doesn’t work in this case, unfortunately… or maybe fortunately?
P.S. I would like to make a small remark – we may have more design patterns in frameworks for functional testing of complex web-applications (not only Selenium-based). In such cases, you may find many cool and interesting patterns working together in one framework (like Decorator, Composite, Factory, Builder, Chain-of-Invocations, PageObject, etc.). However, as I’ve mentioned, such approach requires strong skills in building frameworks architecture and deep programming knowledge in order to keep all together in a workable and maintainable state…
Like this post?
Subscribe to updates from my blog, if you don't want to miss more interesting future posts and materials