На каком scope тестов создавалась новая база и сколько было тестов

Что проверяют

Знаете ли вы, как раннер управляет временем жизни фикстур в .NET, и совпадает ли ваш scope с тем, что он на самом деле даёт. Заодно смотрят, аккуратно ли вы обращаетесь с числами.

Как отвечать

Привяжите ответ к механике xUnit. Конструктор тест-класса выполняется перед каждым тестом, IClassFixture живёт один на класс, ICollectionFixture один на коллекцию классов, а классы из разных коллекций по умолчанию идут параллельно. Отсюда типичный выбор: база поднимается на коллекцию, а изоляция между тестами достигается откатом транзакции или сбросом данных.

Что уместно назвать: контейнер с настоящей СУБД, поднятый на коллекцию, схема из тех же миграций EF Core, что и в проде, WebApplicationFactory для проверок поверх реального контейнера зависимостей.

[Collection("db")]
public class OrderTests
{
    public OrderTests(DbFixture fx) { }
}

Скажите, почему провайдер in-memory не заменяет базу: он не проверяет SQL, ограничения и транзакции, поэтому зелёный тест на нём мало что гарантирует.

Числа давайте разрезом, который виден в сборке: сколько тестов идёт без базы, сколько интеграционных, сколько занимает прогон.

Где спотыкаются

Называют выдуманные круглые цифры. Заявка про ровные пятьдесят юнит-тестов и двадцать интеграционных проверяется одним встречным вопросом про длительность прогона и про то, что эти тесты делают.

Не учитывают параллелизм. Два класса из разных коллекций пишут в одну базу и валят друг друга через раз, а выглядит это как нестабильные тесты. Лечится общей коллекцией или отдельной базой на воркер.

Считают, что фикстура класса пересоздаётся на каждый тест. Она одна на класс, и состояние протекает: контекст EF Core с уже отслеживаемыми сущностями отдаёт данные из кэша, и тест, зелёный в наборе, в одиночку падает.