💡 Инструкция: Выберите один ответ из пяти. На работу отведено 70 минут. В заданиях с кодом опирайтесь на показанный фрагмент и наблюдаемое поведение; в ситуационных — на публичный договор и последствия решения.
Вопрос 1 из 25
Обычный путь в коде зелёный. Как построить проверку «Модульные тесты», чтобы не пропустить различия между отказами?
Dart Dart · Модульные тесты · границы Копировать
test('applies discount to eligible cart', () {
final cart = Cart(items: [Item(price: 1200)], customer: Customer.loyal());
final total = PriceCalculator().total(cart);
expect(total, 1080);
});
// Контекст задания: анализ граничных входов.
Автоматизировать обычный путь «Модульные тесты», а случай «состояние после выполнения» оставить в ручном чек-листе выпуска.
Проверить для «Модульные тесты» только самый сложный случай «состояние после выполнения», считая остальные границы косвенно покрытыми.
Проверить независимо друг от друга: обычный результат, граничный вход, ожидаемое исключение и состояние после выполнения.
Для «Модульные тесты» ограничиться случаем «обычный результат», а остальные входы считать тем же классом отказа.
Во всех спорных входах «Модульные тесты» проверять только отсутствие необработанного исключения, не сравнивая состояние.
Вопрос 2 из 25
Что здесь следует считать правилом «Модульные тесты», а что — лишь деталью текущей реализации?
Dart Dart · Модульные тесты · семантика Копировать
test('applies discount to eligible cart', () {
final cart = Cart(items: [Item(price: 1200)], customer: Customer.loyal());
final total = PriceCalculator().total(cart);
expect(total, 1080);
});
// Контекст задания: проверка семантики фрагмента.
Порядок внутренних вызовов «Модульные тесты» считать публичной гарантией, которую нельзя менять при рефакторинге.
Модульный тест проверяет один наблюдаемый контракт и не должен зависеть от порядка запуска соседних тестов или общей изменяемой глобальной переменной.
Случай «состояние после выполнения» объявить внутренней деталью «Модульные тесты», даже если клиент видит иной результат.
Для «Модульные тесты» считать случаи «обычный результат, граничный вход, ожидаемое исключение и состояние после выполнения» эквивалентными, если программа не завершается аварийно.
Спорный результат «Модульные тесты» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь.
Вопрос 17 из 25
На ревью спорят, достаточно ли одного сквозного теста для «Организация набора». Какой набор действительно раскрывает границы поведения?
Dart Dart · Организация набора · границы Копировать
group('TokenCache', () {
late FakeClock clock;
late TokenCache cache;
setUp(() {
clock = FakeClock(DateTime.utc(2026, 1, 1));
cache = TokenCache(clock);
});
test('expires token at deadline', () {
cache.store('token', expiresAt: clock.now().add(const Duration(minutes: 5)));
clock.advance(const Duration(minutes: 5));
expect(cache.read(), isNull);
});
});
// Контекст задания: анализ граничных входов.
Проверить входы «Организация набора» только на текущей реализации, не закрепляя результат как внешний договор.
Во всех спорных входах «Организация набора» проверять только отсутствие необработанного исключения, не сравнивая состояние.
В сценариях «Организация набора» сравнивать число внутренних вызовов, но не фиксировать публичный результат.
Запустить все границы «Организация набора» одним параметризованным тестом и назначить им одинаковое ожидание.
Развести по отдельным проверкам: общая изменяемая фикстура, зависимость порядка тестов и слишком широкий `setUp`.
Вопрос 18 из 25
На какую гарантию языка или интерфейса можно опереться при разборе этого кода по теме «Организация набора»?
Dart Dart · Организация набора · семантика Копировать
group('TokenCache', () {
late FakeClock clock;
late TokenCache cache;
setUp(() {
clock = FakeClock(DateTime.utc(2026, 1, 1));
cache = TokenCache(clock);
});
test('expires token at deadline', () {
cache.store('token', expiresAt: clock.now().add(const Duration(minutes: 5)));
clock.advance(const Duration(minutes: 5));
expect(cache.read(), isNull);
});
});
// Контекст задания: проверка семантики фрагмента.
Для «Организация набора» считать случаи «общая изменяемая фикстура, зависимость порядка тестов и слишком широкий `setUp`» эквивалентными, если программа не завершается аварийно.
Случай «слишком широкий `setUp`» объявить внутренней деталью «Организация набора», даже если клиент видит иной результат.
Порядок внутренних вызовов «Организация набора» считать публичной гарантией, которую нельзя менять при рефакторинге.
Набор тестов удобно строить по поведению и сценариям, а общую подготовку держать минимальной; слишком глубокие вложенные группы скрывают причину отказа.
Спорный результат «Организация набора» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь.
Вопрос 22 из 25
Что в поведении этого кода гарантировано правилами темы «Проверка допущений», а не случайно совпало в одном запуске?
Dart Dart · Проверка допущений · семантика Копировать
test('rejects payload without required identifier', () {
final payload = <String, Object?>{'name': 'Ada'};
expect(() => UserDto.fromJson(payload), throwsFormatException);
});
// Контекст задания: проверка семантики фрагмента.
Порядок внутренних вызовов «Проверка допущений» считать публичной гарантией, которую нельзя менять при рефакторинге.
Спорный результат «Проверка допущений» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь.
Случай «порядке коллекции или единственном вызове зависимости» объявить внутренней деталью «Проверка допущений», даже если клиент видит иной результат.
В теме «Проверка допущений» отсутствие предупреждения анализатора считать гарантией для любого допустимого входа.
Хорошая проверка явно фиксирует важное допущение: граничное значение, ошибку зависимости, порядок событий или инвариант, который мог бы нарушиться.