Exception stack trace in the Result class
I’ve written quite a few articles on my blog about the use of exceptions vs Result class. I think the best one that summarizes the differences is this: Error handling: Exception or Result? The main idea is that all the differences between various types of failure can be boiled down into the following two categories: Errors we know how to deal with (expected errors), Errors we don’t know how to deal with (unexpected errors).
Crossing aggregate boundaries
Let’s talk about crossing aggregate boundaries in business operations. 1. Preamble In my Pluralsight course about EF Core and encapsulation, I made the recommendation to work with both, the DbContext (also known as Unit of Work) and repositories that work on top of that DbContext, in controllers: public class StudentController : ControllerBase { private readonly StudentRepository _repository; private readonly SchoolContext _context; public StudentController( StudentRepository repository, SchoolContext context) { _repository = repository; _context = context; } } The idea is that you should use repositories to update data in the database and you should use the DbContext to decide whether to keep those updates or roll them back entirely:
Validations vs invariants
I received an interesting question about validations and invariants that I thought I would share with you. 1. Preamble Some time ago, I wrote an article about Always-Valid Domain Model. It’s an important article, so make sure you read it if you haven’t already. One of the points I made in that article is that validation rules are the same concept as domain invariants. Just to recap: an invariant is a condition that must be held true at all times.
Error mapping: whose responsibility is that?
Today, I’ll share a short but interesting question (and my answer to it) about error mapping. Here’s the question itself: Let’s say the domain model returns an error that should not be leaked to the user, so you map it or clean it to remove sensitive data. Should that happen in the domain layer, or in the controller (the application layer)? It seems cleaner to put it in the controller as that’s where all this stuff is done… but, it feels like a domain issue.
Test-first vs Test-last approaches
Today, I’d like to address the topic of when to write tests: before the production code or after. 1. Test-last approach The test-last approach is the regular approach most of us adhere to, and it’s also the most intuitive way to write tests. Basically, you write the application code first and then cover it with tests. Nothing too complicated here; this is the "normal" way to develop software.
Production code vs test code: which one to refactor?
Today, we’ll discuss an interesting question that I hear quite often: how to refactor production code given that you don’t have adequate test coverage. I don’t think I addressed it explicitly in the past, so I’m fixing it with this post. 1. Refactoring and test coverage We all sometimes find ourselves working on legacy projects. In fact, legacy projects are more prevalent than green-field development, simply because all green-field projects eventually join the legacy cohort.
Should you always mock unmanaged dependencies?
Last week, we discussed the difference between managed and unmanaged dependencies: Managed dependencies are out-of-process dependencies that are only accessible through your application; interactions with them aren’t visible to the external world. A typical example is the application database. Unmanaged dependencies are out-of-process dependencies that are observable externally. Examples include an SMTP server and a message bus. Here’s the image that you can use to visualize the difference between managed and unmanaged dependencies (clickable):
What exactly is an unmanaged dependency?
I received an interesting question (two, in fact) about the nature of unmanaged dependencies and their relation to mocking, and I’d like to share my answers with you. We’ll discuss the first question today and we’ll talk about the second one next week. 1. Managed vs unmanaged dependencies In the Unit Testing book, I introduced the concept of managed vs unmanaged dependencies with regards to mocking. (You can also read about them in this article: When to Mock.
Result to Maybe Conversion
Today, we’ll talk about the discussion I had with regards to the small open source library I maintain: C# functional extensions. The discussion was about whether we should enable the conversion from the Result class to Maybe. 1. Result and Maybe First off, what are Result and Maybe? Result is a class that represents a result of an operation. For example, when you are trying to parse an email, you may implement this method like this:
Unit Testing Book Infographic
I wanted to share a quick email with this nice Infographic that Yoan Thirion has created. It’s basically a distillation of the most important concepts from the first 2 parts of my Unit Testing PPP book (click on the image to see a high-resolution version):