C# C# · 30 вопросов · ~85 мин · ⏱ Таймер 25:00 · Сложный ·

Тестирование с xUnit и подменами

Проверяет тесты xUnit, параметризацию, подмены и интеграционные границы. Сценарии отличают полезную проверку поведения от хрупкой проверки реализации, разбирают общее состояние, нестабильные тесты, контрактные наборы и стоимость чрезмерных mock-объектов.

Отвечено: 0 из 30

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 30 вопросов отведено 85 минут. В заданиях с кодом учитывайте указанную конструкцию и не додумывайте отсутствующие условия. После завершения откроются общий результат, тематические шкалы и разбор каждого ответа.

Вопрос 1 из 30

Что относится к Act?

var calculator = new Calculator();      // Arrange
var result = calculator.Add(2, 3);     // Act
Assert.Equal(5, result);               // Assert

Настройка mock Очистка fixture только Создание SUT и данных Один вызов проверяемого поведения Все Assert

Вопрос 2 из 30

Почему expected не стоит вычислять тем же алгоритмом, что production?

Проблема ограничивается скоростью: совпадение алгоритмов не влияет на надёжность проверки xUnit запрещает вычислять ожидаемое значение внутри метода теста Одинаковая ошибка может появиться с обеих сторон и тест пройдёт Expected лучше хранить строкой, чтобы не повторять типы production Тест не скомпилируется, если expected и production используют одинаковые операторы

Вопрос 3 из 30

Что не так с тестом без явного Assert?

[Fact]
public void Valid_document_can_be_parsed()
{
    var document = Parse(validJson);
}

Тест подтверждает лишь то, что выполнение не завершилось исключением Среда неявно добавит Assert.True(document != null) xUnit автоматически пометит тест пропущенным без вызова Assert Тест проверит все закрытые поля возвращённого документа xUnit требует ровно один вызов метода Assert в каждом тесте

Вопрос 4 из 30

Какое имя лучше?

CalculatorTest Works Test1 Method_under_test Divide_when_denominator_is_zero_throws

Вопрос 5 из 30

Почему shared mutable fixture может сделать тесты нестабильными?

public class Tests
{
    private static readonly List<int> Shared = new();
}

Статическое поле копируется для каждого метода теста Общее состояние влияет только на скорость и не может менять результат Список гарантированно очищается сборщиком мусора перед каждым тестом xUnit всегда выполняет весь процесс строго последовательно Тесты меняют одно состояние и начинают зависеть от порядка или параллельного запуска

Вопрос 6 из 30

Когда Theory лучше нескольких Fact?

[Theory]
[InlineData(1, 1)]
[InlineData(2, 4)]
public void Square_matches_table(int value, int expected) =>
    Assert.Equal(expected, value * value);

Для любого async-кода Только когда все входные значения имеют тип int Когда каждый случай требует разной подготовки и поведения Когда одна и та же закономерность проверяется на таблице входов Чтобы скрыть отсутствие Assert

Вопрос 7 из 30

Сколько отдельных тестовых случаев создаст xUnit?

[Theory]
[InlineData(0)]
[InlineData(1)]
[InlineData(-1)]
public void Square_is_non_negative(int value) =>
    Assert.True(value * value >= 0);

Один случай, которому будет передан массив из трёх значений Два — ноль и одно ненулевое значение Ни одного, пока не добавлен атрибут Fact Три — по одному для 0, 1 и -1 Ни одного: Theory не принимает параметры типа int

Вопрос 8 из 30

Когда MemberData предпочтительнее InlineData?

Для сложных или вычисляемых данных вне атрибута Когда данных нет Для изменения production config Чтобы тест стал unit Только когда набор содержит значения bool

Вопрос 9 из 30

Как сохранить читаемость большого набора?

public static TheoryData<TaxCase> Cases => new()
{
    new("threshold-minus-one", 999m, 0m),
    new("at-threshold", 1000m, 100m)
};

Спрятать ожидаемый результат в mock 100 безымянных object[] Удалить граничные случаи, оставив только типичные значения Сериализовать всё в одну строку Именованные TheoryData или record-case с меткой

Вопрос 10 из 30

Когда параметризация вредит?

Когда внутри появляются switch/if по case, разные зависимости и разные причины отказа Параметризация улучшает читаемость даже при разных Arrange и Assert Когда набор содержит несколько числовых значений одного и того же сценария Когда Arrange, действие и проверка полностью совпадают для всех наборов данных Когда проверяемый метод возвращает Task и тесту требуется await

Вопрос 11 из 30

Когда verify вызова важнее проверки состояния?

await service.PayAsync(orderId, token);
paymentGateway.Verify(
    x => x.ChargeAsync(orderId, token),
    Times.Once);

Проверять взаимодействие вместо результата у любого сервиса с зависимостью Только для getters Для чистой функции сложения Когда внешний вызов и есть проверяемый контракт Для private helper

Вопрос 12 из 30

Что проверить у SendAsync?

sender.Verify(x => x.SendAsync(
    It.Is<Message>(m => m.OrderId == orderId && m.Kind == "paid"),
    token), Times.Once);

Аргументы, токен и требуемое число вызовов Значение закрытого поля проверяемого объекта после вызова Размер созданного mock-объекта в памяти Только что метод вызван Содержимое заголовка Authorization, чтобы убедиться в передаче токена

Вопрос 13 из 30

Почему strict mock может быть хрупким?

Strict-режим доступен только интерфейсам и не работает с виртуальными членами классов Strict mock не записывает вызовы, поэтому проверка взаимодействий остаётся пустой Strict mock не поддерживает методы, возвращающие Task, и завершает их синхронно Strict mock делегирует неожиданные вызовы реальному объекту Он падает на любом неописанном взаимодействии, включая несущественные изменения реализации

Вопрос 14 из 30

Чем подменить DateTime.UtcNow?

var time = new FakeTimeProvider(new DateTimeOffset(2026, 1, 1, 0, 0, 0, TimeSpan.Zero));
var sut = new TokenService(time);

Внедрить TimeProvider/clock и управлять временем в тесте Подменить DateTime.UtcNow через reflection на время теста Сравнить только год Изменить системные часы CI Thread.Sleep до нужной даты

Вопрос 15 из 30

Что такое over-mocking?

Подмена собственных простых объектов и деталей реализации вместо проверки наблюдаемого поведения Подмена только медленной внешней системы через тестовый адаптер Несколько Assert, проверяющих один связный результат Параметризация нескольких граничных значений одной теории Использование одного fake для детерминированных часов

Вопрос 16 из 30

Что делает тест интеграционным?

await using var database = await PostgreSqlTestContainer.StartAsync();
await using var app = CreateApplication(database.ConnectionString);
var response = await app.Client.PostAsJsonAsync("/orders", command);

Он находится в отдельной папке Он async Он длиннее 100 строк Проверка нескольких реальных компонентов или границы Он использует Assert.Equal

Вопрос 17 из 30

Почему контейнер целевой СУБД полезнее mock repository для SQL?

Контейнер сам выводит expected из текущей схемы базы Контейнер выполняет каждый тест быстрее unit-теста, поэтому его можно использовать повсюду Контейнер полностью заменяет проверку в production и снимает необходимость миграций Состояние контейнера само очищается между тестами независимо от настроек фикстуры Он воспроизводит schema, constraints, translation, transaction и provider semantics

Вопрос 18 из 30

Как изолировать данные параллельных тестов?

var testId = Guid.NewGuid();
await api.PostAsJsonAsync("/orders", new CreateOrder(testId), token);
var order = await api.GetFromJsonAsync<OrderDto>($"/orders/{testId}", token);

Все используют одну строку с id=1 Thread.Sleep Отдельная база, схема или tenant на тест Отключить параллельность всего набора вместо изоляции данных Сортировать тесты

Вопрос 19 из 30

Что проверяет WebApplicationFactory в ASP.NET Core?

Только controller constructor Приложение через реальный middleware/routing/DI pipeline с тестовым host Разрешение рабочего DNS внешних зависимостей Только JSON serializer отдельно Отрисовку страницы и поведение сценария в настоящем браузере

Вопрос 20 из 30

Почему интеграционные тесты всё равно не заменяют unit-тесты?

// Unit: десятки границ расчёта скидки.
// Integration: один-два сценария, что HTTP -> DI -> DB сохраняет рассчитанную скидку.

Они медленнее и хуже локализуют чистую логику Заменяют полностью Интеграционные тесты покрывают те же ветви быстрее, поэтому unit-тесты избыточны Они не могут Assert Unit нужны только для coverage

Вопрос 21 из 30

Как поступить с flaky-тестом?

[Fact]
public async Task Eventually_completes()
{
    await sut.RunAsync();
}

Добавить 10 retry и забыть Запускать только локально Увеличить все Sleep Найти причину; временно поместить в карантин Удалить Assert

Вопрос 22 из 30

Как добавить полезный контекст к Theory?

output.WriteLine("case={Case}; seed={Seed}; inputCount={Count}",
    testCase.Name, seed, input.Count);

Именованные cases и ITestOutputHelper Логировать весь объект через reflection Печатать пароль входа Очищать вывод перед каждой строкой параметризованного теста Скрыть ожидаемое значение внутри общего вспомогательного метода

Вопрос 23 из 30

Что показывает coverage?

Отсутствие состояний гонки во всех параллельных сценариях Корректность каждой ветви и полноту утверждений Скорость выполнения кода при типичной нагрузке Какой код был выполнен тестами, но не качество проверок и данных Совместимость публичного API с предыдущей версией

Вопрос 24 из 30

Как найти медленные тесты?

Смотреть только общее время CI без разбивки по тестам Собирать длительность по тестам и классам, отделяя работу кода от задержек инфраструктуры Включить подробный вывод и считать самым медленным тест, завершившийся последним Оценить скорость по числу строк в тестовом методе Удалить все async-тесты независимо от их работы

Вопрос 25 из 30

Почему тестовый лог должен иметь redaction?

output.WriteLine("requestId={0}; auth={1}", requestId, "<redacted>");

CI удаляет логи сразу после завершения job Логи CI могут раскрыть токены и строки подключения Только когда тест относится к пользовательскому интерфейсу xUnit не поддерживает строки Тестовые данные считаются публичными внутри CI

Вопрос 26 из 30

Что означает hermetic test?

var clock = new FakeTimeProvider(fixedNow);
var store = new InMemoryOrderStore();
var sut = new OrderService(store, clock);

Тест в Docker обязательно Тест без файлов Тест без случайной сети, времени и общего состояния Тест только static методов Тест без утверждений, который лишь запускает код

Вопрос 27 из 30

Когда contract test особенно полезен?

Для сложения чисел Для независимо выпускаемых клиента и сервиса Чтобы заменить все e2e Только в монолите Для private helper

Вопрос 28 из 30

Что проверяет архитектурный тест?

var result = Types.InAssembly(domainAssembly)
    .ShouldNot().HaveDependencyOn("MyApp.Infrastructure")
    .GetResult();
Assert.True(result.IsSuccessful);

Правила зависимостей между слоями Число сборок каждого поколения во время теста Реальный TLS Соответствие времени выполнения каждого слоя заданному пределу Значения бизнес-расчёта

Вопрос 29 из 30

Почему fake иногда лучше mock?

Он реализует небольшой рабочий контракт и позволяет проверять состояние без хрупких ожиданий вызовов Fake обязан повторять все особенности промышленного хранилища Fake не нуждается в проверке собственного поведения Fake гарантирует меньшую стоимость выполнения, чем любая подмена вызовов Mock применим только к конкретным классам, но не к интерфейсам

Вопрос 30 из 30

Как оценить ценность теста?

// Предпочтительнее:
Assert.Equal(expectedBalance, result.Balance);
// Чем десять Verify внутренних вызовов, не являющихся контрактом.

По общему числу Assert без учёта риска Шанс поймать дефект, скорость и цена поддержки По количеству mock Только по coverage По длине имени тестового метода

Ответьте на все 30 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу