9 Comments
May 29Liked by Daniel Moka

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?

Expand full comment
author

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.

Expand full comment

Well explained, @danielmoka. I loved the examples!

Expand full comment

Arrange-Act-Assert -> the pattern for writing clean and readable tests.

Great article, Daniel! 🙌

Expand full comment

Love it!

Good letter as always.

Testing implementation details is such a lie. Decreases confidence too.

Expand full comment

Your post is very helpful, thanks.

Expand full comment

Hi, I fail to fully understand the first point. What do we mean by public API here? Where does that .Users.First() come from? Is it the framework? ORM? I usually code golang with no framework, it's been a while since I did java or symfony, so I feel like I'm missing something here.

Expand full comment

Great as usual!

Looking forward to watching your course!

Expand full comment

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 !

Expand full comment