---
title: "Discussion on \"Unit Tests Done Right (Part 2)\" | Hashnode"
description: "Discussion on \"Unit Tests Done Right (Part 2)\". How to Test LINQ and Mappings"
url: "https://hashnode.com/posts/unit-tests-done-right-part-2/62790151ffdd2d96c766f2a6"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Unit Tests Done Right (Part 2)](https://zagosk.in/unit-tests-done-right-part-2?utm_source=hashnode&utm_medium=feed)

How to Test LINQ and Mappings

May 9, 2022 · 8 min read · zagosk.in  
Read the article

-   [#dotnet](https://hashnode.com/tag/dotnet)
-   [#dotnetcore](https://hashnode.com/tag/dotnetcore)
-   [#testing](https://hashnode.com/tag/testing)
-   [#csharp](https://hashnode.com/tag/csharp)
-   [#unit-testing](https://hashnode.com/tag/unit-testing)

## Written by

[Aleksei Zagoskin](https://hashnode.com/@azagoskin)

@azagoskin · The Netherlands 🇳🇱

  
[View profile](https://hashnode.com/@azagoskin)

Software Architect, Staff Engineer

Software Architect, Staff Engineer | .NET, C#, microservices | Design and create scalable, high-load, fault tolerant and distributed backend services and Web APIs 👨🏼‍💻

## Responses 2

Markdown supported · ⌘↵ to post

[Roman Izosimov](https://hashnode.com/@RomanIzosimov)

[Jun 28, 2022](https://hashnode.com/posts/unit-tests-done-right-part-2/62790151ffdd2d96c766f2a6/comment/62bb357e7131dfe7a8b5982c)

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.

[Aleksei Zagoskin](https://hashnode.com/@azagoskin)

[Jun 28, 2022](https://hashnode.com/posts/unit-tests-done-right-part-2/62790151ffdd2d96c766f2a6/comment/62bb357e7131dfe7a8b5982c#reply-62bb4448c2f205e7cdb188a3)

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.

[Roman Izosimov](https://hashnode.com/@RomanIzosimov)

[Jun 28, 2022](https://hashnode.com/posts/unit-tests-done-right-part-2/62790151ffdd2d96c766f2a6/comment/62bb334ec2f205e7cdb18670)

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.

[Aleksei Zagoskin](https://hashnode.com/@azagoskin)

[Jun 28, 2022](https://hashnode.com/posts/unit-tests-done-right-part-2/62790151ffdd2d96c766f2a6/comment/62bb334ec2f205e7cdb18670#reply-62bb42dec2f205e7cdb1887e)

Good question, [Roman Izosimov](https://hashnode.com/@RomanIzosimov). 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().