The unit test’s arrange phase is where we write more code. Coding data creation can be cumbersome. The worst scenario happen when we have to fill all class’ properties, even though, we’re only using one property in the test. Besides being tedious, the data creation process can have a lot of code, resulting in less readable and maintainable tests.
To address this problem, we can use the Builder Pattern. The pattern is described in the book design patterns, and solve problems like:
- How can a class create different representation of a complex object?
- How to simplify a class which creates a complex object?
The Builder Pattern brings more flexibility in a complex object’s creation, by delegating the construction of the complex object to a builder object. The builder object can create different representations of the same complex object.
In this post I’m focus on the unit test side, and I’m gonna show you a different version of the Builder Pattern, the Fluent Builder Test Pattern.
The main goal of the Fluent Builder Test Pattern is to facilitate the test data creation. Joining the Builder Pattern and the Fluent Interface Pattern makes the complex object’s creation straight forward.
Does front-end development as a we know it still exist; or has the role evolved into something we no longer recognise? As with evolution in nature, the evolution of "front-end" has resulted in several distinct flavours --- and in my opinion --- an identity crisis.