Post summary: Description with examples of 5 design patterns that is good to know and use in our automation testing.
Design patterns are an interesting topic. They are created to solve common problems in software design. Although design patterns are not reserved only for software development they seem not to be widely discussed in software automation. Maybe this is because the topic sounds complicated. Yes, there are really sophisticated design patterns used to solve complex issues in software development. But also there are easy to understand and adopt design patterns that can significantly improve readability and maintainability of our test automation code.
With series of posts, I’m going to give an overview with examples of some design patterns that can be very useful in our test automation projects. To keep blog neat in this first post I’ll just outline the list of patterns. Each one will be discussed in a separate post with code samples.
Page Objects pattern
This is the most important pattern related to software automation. It enables you to create object repository with UI elements. Elements are separated from tests logic. This pattern makes code much more maintainable and reusable. Page objects design pattern
Facade pattern
The whole idea of facade design pattern is to provide simple and easy to use interface to a larger and more complex code, API or set of APIs. Most likely you don’t need everything provided by the API. So for ease and better maintainability, only API features that are needed gets exposed outside the facade. In this way, you simplify the API usage and you have control over how this external API is used and can prevent misunderstanding or misuse. Facade design pattern
Factory pattern
Factory pattern is used to create objects based on specific rules. You may have several classes implementing an interface. In your code, you do not want to bother defining which concrete class to instantiate or you might not know what object is suitable to get instantiated. This is why you handle the object creation task to the factory which knows exactly what object to create. With factory pattern, object creation is encapsulated. Factory design pattern
Singleton pattern
Singleton pattern is needed when you need exactly one object from a specific class in the whole application. Singleton and Null object patterns
Null object pattern
The idea is to make code simpler and safe by skipping null reference checks. Null object implements given interface and its methods are doing nothing. This makes the null object predictable. You can safely invoke methods on the null object without the threat of a NullReferenceException to break your application. Singleton and Null object patterns
Putting all together
Once you have gone through patterns one by one now it is time to put everything into one project. Complete guide how to use design patterns in automation post is showing how.
