Proposed Solution Day 13

README.md

@@ -75,6 +75,7 @@ A solution proposal will be published here every day during the `Advent Of Craft
 - [Day 10: Dot not use "if" statement.](solution/day10/docs/step-by-step.md)
 - [Day 11: Gather a dependency freshness metric.](solution/day11/docs/step-by-step.md)
 - [Day 12: Make your code open for extension.](solution/day12/docs/step-by-step.md)
+- [Day 13: Find a way to eliminate the irrelevant, and amplify the essentials of those tests.](solution/day13/docs/step-by-step.md)
 
 
 ## Contributors

solution/day13/docs/challenge-done.md

@@ -0,0 +1,67 @@
+## Day 13: Find a way to eliminate the irrelevant, and amplify the essentials of those tests.
+
+### Identifying the building technique
+
+In all tests, we are manipulating Articles with Comments. We want to 
+create them in a simpler and more maintainable way.
+
+We can use [`Test Data Buidler`](https://xtrem-tdd.netlify.app/Flavours/test-data-builders) pattern to achieve this
+purpose.
+
+It will:
+
+- `Facilitate writing` tests by allowing easy creation of inputs or expected data.
+- `Improve test maintainability` by decoupling the creation of objects in tests, and isolating it in a single
+  location (Single Responsibility Principle)
+- Disseminate `functional understanding` in the team through the use of business terms
+- Facilitate the `readability of the tests` by explaining only the data implied in the use case
+
+- We need to identify what is irrelevant and what is essentials in those tests:
+
+Irrelevant: author, comment-text, article's name and content
+Essential: an article contains a comment
+
+### How to create a test data builder
+
+- Let's create a `Test Data Builder` for the `Article`
+    - We would like to have a fluent data builder like this:
+
+```java
+@BeforeEach
+void setup() {
+        article = ArticleBuilder
+        .anArticle()
+        .build();
+}
+```
+
+We then generate the code from usage. 
+We end up with a builder class with the methods.
+
+- We implement the builder with the build method (simplest as possible)
+
+- We adapt the tests
+- We iterate on the builder
+
+### Optimizations
+
+- Let's improve readability of our tests by
+    - simplifying them
+    - removing duplication
+
+### Bonus: additional optimizations with other libs
+
+We could remove call to the builder from the tests by creating a DSL and using `Higher Order Function`.
+
+- We could also use a library to get random `String` data for our tests (they do not impact the results of the behavior and create noise)
+    - We can use `Instancio` to do so
+
+- By using it, it makes explicit that some required data do not influence the behavior
+
+>**Tip of the day: Your test data and assertions can be abstracted to improve readability and maintainability.**
+
+### Share your experience
+
+How does your code look like? Anything you'd like to add?
+
+Please let everyone know in the discord.