It not only points out the wrong but also shows the right approach in each example. Very well structured newsletter.
I only do not understand fully the 4th example, though. Should I change the existing or add a new implementation to construct an object with less parameters just for test clarity, in this example?
As for the 4th example: You don't need a new constructor. You just create an CreateEmployeeWithId method with only one parameter the ID. Then inside the method you construct the object with the non-relevant data (+ the ID), so they are not visible in the test, so dont add noise.
It not only points out the wrong but also shows the right approach in each example. Very well structured newsletter.
I only do not understand fully the 4th example, though. Should I change the existing or add a new implementation to construct an object with less parameters just for test clarity, in this example?
Thanks for the feedback.
As for the 4th example: You don't need a new constructor. You just create an CreateEmployeeWithId method with only one parameter the ID. Then inside the method you construct the object with the non-relevant data (+ the ID), so they are not visible in the test, so dont add noise.
Hope it clarifies it.
Well explained, @danielmoka. I loved the examples!
Arrange-Act-Assert -> the pattern for writing clean and readable tests.
Great article, Daniel! 🙌
Love it!
Good letter as always.
Testing implementation details is such a lie. Decreases confidence too.
Your post is very helpful, thanks.
Great as usual!
Looking forward to watching your course!
Can you provide more details on the first case ?
It seems like we want to wrap the logic in a Fake class, but what if this logic change ? The Fake class won’t compile without change or am I wrong ?
Thanks !