Alexey Zagoskin yes, agree, it is good to cancel a token when/if a connection is interrupted, but I've never used this before. Could you please refer to a web page or example about that, I mean how to detect the interruption and react.

Don't know if you are going to continue the article series, but could suggest to reveal us your vision of testing DI containers definitions (especially to check if a service is defined in a container or not, quite repetitive errors), testing configuration (maybe both presence and overrides), testing of log records, testing of routes and access rights of API endpoints.

Sometimes in the arrange section of tests we can see repeatable (or very similar) code blocks and looks like it is a good candidate to extract identical (or very similar) code to a method to reuse by several tests. But I think the readability and maintainability of the test could degrade. What do you think about this? Should we apply the same best practices for writing tests as for business logic? There are very similar code in the Arrange sections of Should_return_user_by_id_unless_deleted and Should_return_null_when_user_is_deleted tests, which could be extracted, so I wonder if you prefer to duplicate or not in such cases.

What tool you are using to check test coverage? You've shared a screenshot with us but not its name :)

When you check an exception message do you think it might be worth using a constant template for the error message to don't break a test just because you have changed the message, or better to have the test broken on each change of the message and amend it accordingly?

Test Strategy for Example 2 maybe should contain checking that we don't change any other user's entity field but only password. But this could mess up the test. What do you think? What is your assessing path to decide whether include or not anything to test?

I know it is out of the scope of the topic but I'd like to know your opinion, what is the strategy of using cancellation tokens in your examples. I guess the UserManager is invoked by an action (as part of a controller) and then from UserManager you call a repo and pass ct to it. Inside repo you pass ct to linq async operation. What is the benefit to do that? What is the source of the ct? Who and why might cancel the token in the presented chain of calls?

Hi Alexey, thank you a lot for the knowledge sharing and insides, it is very interesting, keep going!