The Humble Object Pattern

[giscus[bot]]

The Humble Object Pattern

The Humble Object Pattern is a design pattern to make especially unit testing easier with the goal of separating behaviors that are easy to handle (domain logic) from behaviors that are hard to handle (like external events or dependencies).
So let's have a look at what it is and how you can utilize it.

https://steven-giesel.com/blogPost/47acad0a-255c-489b-a805-d0f46bde23e5/the-humble-object-pattern

[toupswork]

Here's another tip that I love. Create a delegate and add it to dependency injection with a lambda expression as the implementation. For example:

public delegate Guid CreateGuid();

/// 
services.AddSingleton<CreateGuid>(()=> Guid.NewGuid());

Now any classes that need to generate a Guid can accept the delegate as a dependency. Then when you write your unit test, it's super easy to mock and your test will be deterministic because you can control the exact Guid value. Do this for Dates or Random, too, or anyhing that can prevent your test from being deterministic

[toupswork]

I could have also omitted the outer lambda and just added Guid.NewGuid as the implementation

[linkdotnet]

I do like that approach - I saw that the first time some years back and I disliked it as you have to have a public delegate.
I don’t know but it felt (and somewhat still feels) „dirtier“ than a public interface.

But the simplicity is elegant. I do have to admit that.
The good part is that .NET introduced some abstractions around time (TimeProvider) which I really love.

[toupswork]

Yes. So the only one I still have left is the Guid Generator in my work project