It would be more convincible if you can elaborate "when you overcomplicate simple things", which I think you are talking about using Builder Pattern for simple cases. You are right, Builder Pattern is not suitable for those scenarios, that's why Moq is handy here.

I am curious about the use cases in your project mentioned in the comment. I guess you have a model class that its state is defined by a set of parameters inside the class. And the Builder Pattern allows you to stage some default parameters, while still allows you to override some parameters when needed. However, I believe Moq can still suit your needs, where you stage a default object and overwrite it later. But that's a personal preference. If the constructor is sufficient, then use constructor for sure. If you like the OO method chain, then use the Builder pattern style.

No, I am not intended to fight against Builder Patter in general.

I have been using the Builder Pattern for a long time. But after I refactored legacy code for a few projects, I saw lots of overhead in updating the Builder classes. Even worse, I have discovered two categories of bad tests: (1) some business logic gets leaked into Builder classes; (2) Builder classes are already non-relevant to the original class that tests are only testing the "Builder classes".

Thank you for your comment. I agree with most of you said, and they are all good points.