9 Comments
User's avatar
alpsavas's avatar

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
Daniel Moka's avatar

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
Raul Junco's avatar

Well explained, @danielmoka. I loved the examples!

Expand full comment
Petar Ivanov's avatar

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

Great article, Daniel! 🙌

Expand full comment
Tiger Abrodi's avatar

Love it!

Good letter as always.

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

Expand full comment
Hùng Trần's avatar

Your post is very helpful, thanks.

Expand full comment
Albert Balbastre Morte's avatar

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
Maximiliano Contieri's avatar

Great as usual!

Looking forward to watching your course!

Expand full comment
Tom's avatar

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