CAP theorem of domain modeling
Some time ago, I wrote an article about a trilemma in domain modeling. It resonated with a lot of people, and I’d like to elaborate on this topic with this email. In short, the trilemma states that you can’t have all 3 of the following attributes: Domain model completeness — When all the application’s domain logic is located in the domain layer, i.e. not fragmented. Domain model purity — When the domain layer doesn’t have out-of-process dependencies.
Inheritance in unit tests
Last time, I wrote a follow-up to this article about whether or not you should unit test an abstract class. Now, I’d like to write a small follow-up to that follow-up 😊 To recap, here are the main points from the article and the previous follow-up: You shouldn’t unit test abstract classes directly because they are implementation details. Test them indirectly, via the concrete classes that inherit from the abstract class.
Unit testing a non-abstract base class?
Some time ago, I posted an article about whether or not you should unit test an abstract class. It generated some[what] heated discussion in the comment section, which made me feel like in good old days when I just started writing on the blog :) Lots of debates in the comments, borderline name-calling. That was.. intense. Frankly, it sometimes hard to motivate myself to continue writing, but such arguments help reignite the spark.
How to wrap unmanaged dependencies
In the previous email, we talked about mocking types that you own. To re-iterate, this guideline is about writing your own adapters on top of third-party libraries and mocking those adapters instead of the underlying types. This is beneficial because: You often don’t have a deep understanding of how the third-party code works. Even if that code already provides built-in interfaces, it’s risky to mock those interfaces, because you have to be sure the behavior you mock matches what the external library actually does.
Mocking types that you own
I’ve personally come through quite a journey when it comes to mocking in unit testing. I started (just like most people) by using mocks in almost all of my tests. Then, I went to the opposite side of the spectrum and tried to avoid mocks altogether. Finally, I settled on mocking only one particular type of dependencies. That type is unmanaged dependencies — out-of-process dependencies, interactions which which are observable externally (SMTP service, Message bus, etc.
Seen vs unseen in unit testing
One of the main reasons why I wrote the Unit Testing book (despite there being quite a few unit testing books already) is because the existing books and other resources rarely discuss economic implications of unit testing, whereas in my view, this is one of the most important discussions to have in any area of software development. In economics, there’s the notion of seen vs unseen, which means that, when implementing a policy, you need to focus on both sides of it:
How to strengthen requirements for pre-existing data
Check out my latest article: How to Strengthen Requirements for Pre-existing Data This article is a response to a question I receive quite often nowadays: how to change validation requirements (particularly, strengthen those requirements) for data that already exists in the database. Until next week, Vlad
When do you need a persistence model?
This email is about scenarios in which you need a separate persistence model in addition to your domain model. I know, you have probably subscribed to this list because of my unit testing content, but I still receive questions about Domain-Driven Design (which I’ve spent several years writing about), and some of them are quite interesting. I’ll be posting the most interesting of those questions here too. Hope you don’t mind.
When to mock
Check out my latest article: When to Mock I also did a short interview about my book here: Short interview about unit testing Until next week, Vlad
Unit Testing Dependencies: The Complete Guide
Check out my latest article: Unit Testing Dependencies: The Complete Guide This is an extended version of what I wrote in Chapter 2 of my Unit Testing book — with more images and examples. Until next week, Vlad