Юнит-тесты на внедрение зависимостей Microsoft.Extensions.DependencyInjection

C постепенным переходом проектов на .NET Core фреймворки все большую популярность набирает стандартная реализация внедрения зависимостей от Microsoft. На мой взгляд эта реализация все еще уступает Autofac, но в этой статье речь пойдет не об этом. При использовании любого фреймворка для внедрения зависимостей рано или поздно разработчики сталкиваются с проблемой забытой или неправильной регистрации зависимостей, что влечет за собой ошибку в рантайме приложения.

Хорошо, если разработчик, привнеся ошибку в код, самостоятельно ее обнаружил во время отладки, а если нет? Если ошибка ускользнула от разработчика, QA-инженера, прошла через все стадии доставки изменений кода до пользователей и оказалась в production? В этом случае есть вопросы к контроля качества в команде, однако, нельзя отрицать тот факт, что работа с зависимостями в .NET приложении несет в себе большой регрессионный риск.

В основе юнит-тестирования внедрения зависимостей лежит простая идея — отлавливать проблемы с DI в приложении еще на этапе автоматического запуска юнит-тестов, настроенного в вашем ci/cd пайплайне. Дальнейшее повествование будет вестись в контексте ASP.NET Core приложения.

Пишем юнит тесты

Перед написанием юнит тестов определю некоторые требования к ним. Тесты должны:

• Поддерживать автоматический assembly-сканнинг всех точек входа в приложение, в случае ASP.NET Core это будут MVC контроллеры.

• Иметь базовый класс или набор extension-методов для переиспользования в множестве проектов.

• Поддерживать проверку внедрения зависимостей для BackgroundServices, слушателей ServiceBus или других кастомных классов в Console Applications.

Последнее требование специфично конкретно для моего проекта, но уверен, что практически в любом приложении с микросервисной архитектурой можно найти работу с брокерами сообщений, фоновыми сервисами, джобами и триггерами. Тесты можно адаптировать под любой вид зависимостей.

Целевым фреймворком для указанного ниже кода является .NET 5, однако, код легко адаптировать и для .NET 6+. Начнем с основы и напишем базовый класс для тестирования зависимостей API контроллеров:

public abstract class ApiDependencyInjectionTestBase<TStartup> where TStartup : class {     protected IEnumerable<object> ResolveEntryPoints()     {         var host = WebHost.CreateDefaultBuilder()            .UseStartup<TStartup>()            .Build();          var serviceProvider = host.Services;         using var serviceScope = serviceProvider.CreateScope();          var baseClassType = typeof(ControllerBase);         var typesToResolve = typeof(TStartup).Assembly             .GetTypes()             .Where(x => x.IsClass && !x.IsInterface && !x.IsAbstract && baseClassType.IsAssignableFrom(x))             .ToList();          foreach (var typeToResolve in typesToResolve)         {             yield return ActivatorUtilities.CreateInstance(serviceProvider, typeToResolve);         }     } }

Базовый generic-класс содержит один единственный метод ResolveEntryPoints , который внутри себя создает WebHost на основе заданного Startup класса, с помощью рефлексии ищет всех наследников базового класса ControllerBase в сборке и пытается их внедрить вместе со всеми зависимостями. В случае, если какая-нибудь из зависимостей не будет должным образом зарегистрирована, при попытке вызова ActivatorUtilities.CreateInstance() будет выброшено соответствующее исключение. В реализации юнит теста нам остается только использовать Startup класс в качестве generic-типа и проверить, что список внедренных контроллеров не пустой и действительно содержит объекты:

public class ApiDependencyInjectionTests : ApiDependencyInjectionTestBase<Startup> {     [Fact]     public void DependenciesRegistrationTest()     {         var instances = ResolveEntryPoints();          Assert.NotEmpty(instances);         foreach (var instance in instances)         {             Assert.NotNull(instance);         }     } }

В своем проекте я поставляю базовый ApiDependencyInjectionTestBase класс в NuGet пакете и пишу простой тест на внедрение зависимостей в каждом MVC-приложении.

Однако, кроме ASP.NET приложений конкретно в моем проекте используются еще и Console Applications, которые хостят разного рода фоновые задачи или обработчики сообщений от брокеров. Для этих целей напишем чуть более сложный базовый класс WebJobsDependencyInjectionTestBase:

 public abstract class WebJobsDependencyInjectionTestBase {     private IServiceProvider serviceProvider { get; set; }      protected void SetUpServiceProvider(         string appSettingsPath,         Action<IConfiguration> setConfiguration,         Action<IServiceCollection> configureServices)     {         var configuration = new ConfigurationBuilder()            .AddJsonFile(appSettingsPath)            .Build();          setConfiguration(configuration);          var host = new HostBuilder()             .ConfigureHostConfiguration(configBuilder =>             {                 configBuilder.AddConfiguration(configuration);             })             .ConfigureServices(configureServices)             .Build();          serviceProvider = host.Services;     }      protected IEnumerable<object> ResolveEntryPoints(Assembly assembly, params Type[] additionalTypesToResolve)     {         using var serviceScope = serviceProvider.CreateScope();          var messageHandlerInterface = typeof(IMessageHandler);         var backgroundServiceBaseClass = typeof(BackgroundService);         var typesToResolve = assembly             .GetTypes()             .Where(x => x.IsClass && !x.IsInterface && !x.IsAbstract &&             (messageHandlerInterface.IsAssignableFrom(x) || backgroundServiceBaseClass.IsAssignableFrom(x)))             .ToList();         typesToResolve.AddRange(additionalTypesToResolve);          foreach (var typeToResolve in typesToResolve)         {             yield return ActivatorUtilities.CreateInstance(serviceProvider, typeToResolve);         }     } }

Поскольку конфигурирование ServiceProvider в случае отсутствия Startup класса является чуть более сложной задачей и требует дополнительных параметров, выделим отдельный метод SetUpServiceProvider. В этот раз нам пришлось отдельно создавать конфигурацию приложения с помощью пути к файлу настроек appsettings.json и использовать Action параметры для конфигурирования ServiceProvider. Метод ResolveEntryPoints также усложнился и использует для Assembly-сканнинга интерфейс IMessageHandler и базовый класс BackgroundService . Кроме этого добавлена возможность принимать кастомный список типов, которые могут использоваться в конкретном приложении как точки входа.

Вот так может выглядеть реализация теста:

public class WebJobsDependencyInjectionTests : WebJobsDependencyInjectionTestBase {     [Fact]     public void DependenciesRegistrationTest()     {         SetUpServiceProvider(appSettingsPath: "appsettings.json",             configuration => Program.Configuration = configuration,             services => Program.ConfigureServices(services));          var instances = ResolveEntryPoints(typeof(MesageHandlerWithDependency).Assembly, typeof(CustomClassWithDependency));          Assert.NotEmpty(instances);         foreach (var instance in instances)         {             Assert.NotNull(instance);         }     } }

При этом отмечу, что в Program класс необходимо сделать публичным, добавить метод public static ServiceProvider ConfigureServices(IServiceCollection services) и свойство public static IConfiguration Configuration { get; set; }.В метод ResolveEntryPoints необходимо передать Assembly для сканирования, а также при необходимости список кастомных классов для резолва.

Заключение

Юнит-тесты на внедрение зависимостей могут покрыть большую часть возможных проблем с зависимостями. Приведенная реализация тестов является рабочим решением, но стоит помнить, что в реальных проектах часто необходимо проверять дополнительные зависимости, например, если вы используете FromServices атрибуты, разного рода Middlewares, профили Automapper, обработчики MediatR и т.д.

C демонстрационным проектом и тестами можно ознакомиться на GitHub