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

Хорошо, я поясню.

1. Юнит-тест это то, что тестирует отдельный аспект (допустим вызов) отдельного компонента. Твои тесты вполне имеют право на жизнь, но это совсем не юнит-тесты. У тебя тестируется вся связка регистрации сервисов, создания сервиса, его зависимостей, зависимостей зависимостей и т.д. Это вполне можно сделать частью интеграционных тестов, но не совосем понятно нужно ли это, потому что регистрация и создание объектов в интеграционных тестах и так будут покрываться тестами других вызовов. Вот, посмотри:

using FakeItEasy;
using FluentAssertions;
using Microsoft.Extensions.DependencyInjection;
using Xunit;

namespace Foo;

public void ConfigureServices(IServiceCollection services)
{
    services.AddTransient<Foo>();
    services.AddTransient<IBar, Bar>();
}

public class Foo
{
    public IBar Bar { get; init; };

    public Foo(IBar bar) =>  _bar = bar ?? throw new ArgumentNullException(nameof(bar));
}

public interface IBar { }

public class Bar: IBar { }

public class Tests
{
    ///<summary>
    /// Это настоящий unit тест.
    ///</summary>
    [Fact]
    public void ConfigureServices_should_register_Foo()
    {
        ServiceCollection services = new();
        Startup sut = new();
        sut.ConfigureServices(services);
        services.Should().Contain(sd => sd.ServiceType == typeof(Foo));
    }

    ///<summary>
    /// И это unit тест.
    ///</summary>
    [Fact]
    public void ConfigureServices_should_register_IBar()
    {
        ServiceCollection services = new();
        Startup sut = new();
        sut.ConfigureServices(services);
        services.Should().Contain(sd => sd.ServiceType == typeof(IBar));
    }

    ///<summary>
    /// И вот это unit тест.
    ///</summary>
    [Fact]
    public void Foo_constructor_should_check_null_bar()
    {
        FluentActions.Invoking(() => new Foo(null!)).Should().Throw<ArgumentNullException>()
            .Which.ParamName.Should().Be("bar");
    }

    ///<summary>
    /// И вот еще один unit тест.
    ///</summary>
    [Fact]
    public void Foo_constructor_should_initialize_Bar()
    {
        var bar = A.Fake<IBar>();
        Foo sut = new(bar);
        sut.Bar.Should().BeSameAs(bar);
    }
}

Тут мы отдельно тестируем регистрацию (т.е. метод ConfigureServices) и отдельно тестируем конструктор(ы). А тестировать "все до кучи" следует уже в интеграционных тестах.

2. Что касается твоего предпоследнего куска кода. Ты создаешь scope:

using var serviceScope = serviceProvider.CreateScope();

что абсолютно правильно. Но затем, почему-то создаешь объекты не в нем, а используя исходный IServiceProvider:

yield return ActivatorUtilities.CreateInstance(serviceProvider, typeToResolve);

Если у тебя какая-то зависимось зарегистрирована как scoped, то получишь "false negative" в виде неожиданного exception. Правильно было бы:

yield return ActivatorUtilities.CreateInstance(serviceScope.ServiceProvider, typeToResolve);

И даже тогда остается огрех. Из-за using serviceScope = ... объекты созданные в нем будут все еще доступны после того как serviceScope.Dispose() вызовет Dispose() для всех созданных через него объектов. В твоем случае это никакой роли не играет (ты ничего больше у этих объектов не вызываешь, к тому же из-за конструкции yield Dispose() вызовется только после перечисления всей коллекции), но все равно подобный код лучше не писать, т.к. если не здесь, то в другом месте можно наступить на те еще грабли. Я уверен, что все хоть однажды наступали на очень похожие грабли с EF и LINQ:

public IEnumerable<Person> GetAdults()
{
    using MyDbContext context = new();
    return context.People.Where(p => p.Age > 18);
}

На первый взгляд все нормально, но что будет на самом деле, я думаю, тут объяснять не надо.

PS. Блок кода под спойлер никак не помещается (если писать в режиме markdown)?

Это был намёк :) Просто мы у себя валидируем, интересно в чем преимущество такого юнит-теста, может нам тоже надо так делать