Thanks. It really is.

Samuel Sunday , indeed, but at the same time exciting 😅

Tanks Samuel. Good question, what is clear at this point (at least for me, but there are different opinions on this) is that the world we’re used to is changing, and we’re in the very beginning of this change.

But we have to follow the AI ​​progression 😉

Ah, it's Rider, it offers this stuff out of the box. I believe Resharper has it as well.

Good call. Sometimes I don't check the exception message at all, just exception type and properties (for custom exceptions).

We may consider these things for testing: Happy path e.g. return value is correct / expected exception gets thrown / messages get published etc. All if-else-switch branches. Edge cases such as awkward input parameters (int.MaxValue/MinValue/0, long strings, nulls, empty strings etc). The order of method calls (e.g. validation goes before we save data to the database).

Good point! Your assumption is absolutely correct, cancellation tokens come from controllers and do the cancellation, for instance, if/when a connection between the client and the server is interrupted. In these cases we may want to cancel "get" queries while let others finish.

This article is supposed to be the last one in this short series. At the moment I’m working on an open source project which I’m going to blog about later on. The amount of work is rather decent so I’m afraid I don’t have ETA at that point. As for DI, routing and security, I prefer to cover these with integration tests. Nevertheless, the first two could be nicely covered by unit tests.

Good question, Roman Izosimov . Usually I prefer to declare simple things explicitly in the "arrange" section, while more complex setup may deserve reusable methods or extension methods for Fixture e.g. F.CreateCustomerWithOrders().