День 2597. #ЗаметкиНаПолях
5 Архитектурных Тестов Необходимых Каждому .NET-Проекту. Окончание
Начало
Продолжение

4. Тесты видимости
Обработчики команд и запросов — это детали реализации. Они разрешаются через внедрение зависимостей, на них нет прямых ссылок. Но большинство разработчиков по умолчанию делают их публичными. Это просто привычка. Проблема в том, что на публичный обработчик можно напрямую ссылаться из другого слоя, минуя созданные вами абстракции:

public class VisibilityTests : BaseTest
{
  [Fact]
  public void CommandHandlers_ShouldBeInternal()
  {
    Classes().That()
     .ImplementInterface(typeof(ICommandHandler<>))
     .Should().BeInternal()
     .Check(Architecture);
  }

  [Fact]
  public void QueryHandlers_ShouldBeInternal()
  {
    Classes().That()
     .ImplementInterface(typeof(IQueryHandler<,>))
     .Should().BeInternal()
     .Check(Architecture);
  }
}

Если вас беспокоит, что DI не обнаружит внутренние классы, не волнуйтесь. Сканирование сборок обнаруживает их без проблем. Вы можете распространить это и на другие типы. Например, гарантировать, что конфигурации EF Core являются внутренними, поскольку нет причин, по которым OrderConfiguration должен быть виден за пределами инфраструктуры.

5. Тесты защиты от зависимостей
Тесты уровня защиты предотвращают ссылки на ваши собственные сборки. Но библиотеки инфраструктуры могут проникать через транзитивные ссылки NuGet. Ваш уровень предметной области не должен знать об Entity Framework. Ваш уровень приложения не должен знать о Npgsql. Компилятор не предотвратит этого, если пакет доступен транзитивно:

public class DependencyGuardTests : BaseTest
{
  [Fact]
  public void Domain_ShouldNotDependOn_EF()
  {
    Types().That()
     .ResideInAssembly(DomainAssembly).Should()
     .NotDependOnAnyTypesThat()
     .ResideInNamespace("Microsoft.EntityFrameworkCore")
     .Check(Architecture);
  }
}

Добавьте все библиотеки, которые подходят для вашего проекта.

Итого
Архитектурные правила, существующие только в документации, будут нарушены. Вопрос только, когда. Все эти тесты выполняются за миллисекунды и не требуют никакой инфраструктуры. Они располагаются рядом с вашими модульными тестами и запускаются при каждой сборке. Архитектурные тесты — это страховочная сеть, которая выявляет нарушения до того, как они попадут в продакшн. Начните с тестов зависимостей слоёв. Их настройка занимает пять минут, и они выявляют наиболее опасные нарушения. Затем добавьте остальные по мере роста вашей кодовой базы.

Источник: https://www.milanjovanovic.tech/blog/5-architecture-tests-you-should-add-to-your-dotnet-projects