Платформенные различия Android, iOS и Web — бесплатный тест онлайн

Вопрос 1 из 30

На ревью спорят, достаточно ли одного сквозного теста для «Условный код». Какой набор действительно раскрывает границы поведения?

import 'share_stub.dart'
  if (dart.library.io) 'share_io.dart'
  if (dart.library.js_interop) 'share_web.dart';

ShareGateway createShareGateway() => platformShareGateway();

// Контекст задания: анализ граничных входов.

Составить отдельные сценарии для границ: несовместимые сигнатуры условных реализаций, импорт неподдерживаемой библиотеки и отсутствие запасной реализации. Объединить «несовместимые сигнатуры условных реализаций» и «импорт неподдерживаемой библиотеки» в один тест «Условный код» с общим ожидаемым исходом. Автоматизировать обычный путь «Условный код», а случай «отсутствие запасной реализации» оставить в ручном чек-листе выпуска. Проверить для «Условный код» только самый сложный случай «отсутствие запасной реализации», считая остальные границы косвенно покрытыми. Для «Условный код» ограничиться случаем «несовместимые сигнатуры условных реализаций», а остальные входы считать тем же классом отказа.

Вопрос 2 из 30

На какую гарантию языка или интерфейса можно опереться при разборе этого кода по теме «Условный код»?

import 'share_stub.dart'
  if (dart.library.io) 'share_io.dart'
  if (dart.library.js_interop) 'share_web.dart';

ShareGateway createShareGateway() => platformShareGateway();

// Контекст задания: проверка семантики фрагмента.

Для «Условный код» считать случаи «несовместимые сигнатуры условных реализаций, импорт неподдерживаемой библиотеки и отсутствие запасной реализации» эквивалентными, если программа не завершается аварийно. Случай «отсутствие запасной реализации» объявить внутренней деталью «Условный код», даже если клиент видит иной результат. Вывод делают по поведению текущей реализации «Условный код» на обычном входе. Условные импорты выбираются на этапе компиляции и должны предоставлять совместимый интерфейс; проверка `Platform.isAndroid` недоступна в веб-сборке без подходящей абстракции. Спорный результат «Условный код» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь. Дополнительные границы «Условный код» при таком рассуждении считают избыточными. Порядок внутренних вызовов «Условный код» считать публичной гарантией, которую нельзя менять при рефакторинге. Предполагается, что компиляция уже подтверждает весь договор «Условный код».

Вопрос 3 из 30

Какое изменение показанного кода исправляет правило «Условный код», а не маскирует один его симптом?

import 'share_stub.dart'
  if (dart.library.io) 'share_io.dart'
  if (dart.library.js_interop) 'share_web.dart';

ShareGateway createShareGateway() => platformShareGateway();

// Контекст задания: выбор места исправления.

Скопировать защиту «Условный код» во все найденные места вызова и считать повторение единым исправлением. Добавить в «Условный код» специальный флаг только для одного экрана или сервиса, сохранив общий контракт. В решении «Условный код» перехватывать любое исключение и возвращать нейтральное значение без указания причины. Оставить поведение «Условный код» прежним, но заменить сообщение об ошибке на более подробное. Сделать условные реализации совместимыми по API и предоставить явную ветвь для неподдерживаемой платформы.

Вопрос 4 из 30

Какой сценарий должен стать постоянной проверкой после исправления «Условный код»?

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

Вопрос 5 из 30

Что должно оставаться неизменным при замене реализации темы «Условный код»?

Условный импорт должен выбирать реализацию на этапе компиляции без изменения публичного договора. Из «Условный код» возвращать строку или `null`, а смысл результата разбирать отдельно в каждом клиенте. В договоре «Условный код» описать только успешный путь, оставив спорные входы на усмотрение реализации. Перед вызовом «Условный код» заставить клиента повторять валидацию, не описывая отказ самого компонента. Включить в договор «Условный код» конкретный способ хранения состояния вместо наблюдаемого результата.

Вопрос 6 из 30

Что в поведении этого кода гарантировано правилами темы «Разрешения», а не случайно совпало в одном запуске?

Future<LocationResult> requestLocation() async {
  final status = await permissions.location.status;
  if (status.isDenied) await permissions.location.request();
  final current = await permissions.location.status;
  return current.isGranted ? location.read() : const LocationResult.denied();
}

// Контекст задания: проверка семантики фрагмента.

Случай «возврат приложения из фона» объявить внутренней деталью «Разрешения», даже если клиент видит иной результат. Разрешение платформы — изменяемое состояние: пользователь может отказать или отозвать его; запрос должен быть контекстным, а отказ иметь рабочую ветвь. Для «Разрешения» считать случаи «первый отказ, постоянный отказ, отзыв разрешения в настройках и возврат приложения из фона» эквивалентными, если программа не завершается аварийно. Спорный результат «Разрешения» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь. Порядок внутренних вызовов «Разрешения» считать публичной гарантией, которую нельзя менять при рефакторинге.

Вопрос 7 из 30

На ревью просят не размножать проверки по вызывающему коду. Какое исправление для «Разрешения» отвечает этому требованию?

Future<LocationResult> requestLocation() async {
  final status = await permissions.location.status;
  if (status.isDenied) await permissions.location.request();
  final current = await permissions.location.status;
  return current.isGranted ? location.read() : const LocationResult.denied();
}

// Контекст задания: выбор места исправления.

Запрашивать разрешение в контексте действия и повторно проверять его перед использованием возможности. Добавить обработку «первый отказ» в ближайший вызывающий метод, не меняя общий компонент «Разрешения». Скопировать защиту «Разрешения» во все найденные места вызова и считать повторение единым исправлением. Добавить в «Разрешения» специальный флаг только для одного экрана или сервиса, сохранив общий контракт. В решении «Разрешения» перехватывать любое исключение и возвращать нейтральное значение без указания причины.

Вопрос 8 из 30

Фрагмент выглядит убедительно на типичных данных. Какие входы по теме «Разрешения» нельзя проверять одним общим ожиданием?

Future<LocationResult> requestLocation() async {
  final status = await permissions.location.status;
  if (status.isDenied) await permissions.location.request();
  final current = await permissions.location.status;
  return current.isGranted ? location.read() : const LocationResult.denied();
}

// Контекст задания: анализ граничных входов.

Автоматизировать обычный путь «Разрешения», а случай «возврат приложения из фона» оставить в ручном чек-листе выпуска. Проверить входы «Разрешения» только на текущей реализации, не закрепляя результат как внешний договор. Во всех спорных входах «Разрешения» проверять только отсутствие необработанного исключения, не сравнивая состояние. Задать самостоятельные ожидания для случаев: первый отказ, постоянный отказ, отзыв разрешения в настройках и возврат приложения из фона. Проверить для «Разрешения» только самый сложный случай «возврат приложения из фона», считая остальные границы косвенно покрытыми.

Вопрос 9 из 30

Какой контракт по теме «Разрешения» отделяет наблюдаемое поведение от внутренних шагов?

Разрешение является изменяемым состоянием, а не одноразовым флагом успешной установки. Из «Разрешения» возвращать строку или `null`, а смысл результата разбирать отдельно в каждом клиенте. В договоре «Разрешения» описать только успешный путь, оставив спорные входы на усмотрение реализации. Включить в договор «Разрешения» конкретный способ хранения состояния вместо наблюдаемого результата. Перед вызовом «Разрешения» заставить клиента повторять валидацию, не описывая отказ самого компонента.

Вопрос 10 из 30

Какой сценарий должен стать постоянной проверкой после исправления «Разрешения»?

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

Вопрос 11 из 30

Какое утверждение о показанном фрагменте и теме «Жизненный цикл» опирается на реальную гарантию Dart или используемого интерфейса?

class SessionLifecycle with WidgetsBindingObserver {
  @override
  void didChangeAppLifecycleState(AppLifecycleState state) {
    if (state == AppLifecycleState.inactive || state == AppLifecycleState.paused) {
      sessions.persistDraft();
    }
  }
}

// Контекст задания: проверка семантики фрагмента.

Спорный результат «Жизненный цикл» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь. Для «Жизненный цикл» считать случаи «приостановка и уничтожение процесса, перезагрузка вкладки и ограничение фоновой работы» эквивалентными, если программа не завершается аварийно. Порядок внутренних вызовов «Жизненный цикл» считать публичной гарантией, которую нельзя менять при рефакторинге. Клиенту «Жизненный цикл» предлагают самостоятельно уточнять смысл спорного результата. Android, iOS и Web по-разному приостанавливают приложение и ограничивают фон; сохранение критического состояния нельзя откладывать только до идеального завершения. Случай «ограничение фоновой работы» объявить внутренней деталью «Жизненный цикл», даже если клиент видит иной результат.

Вопрос 12 из 30

После одного успешного запуска фрагмент признали готовым. Какой набор случаев по теме «Жизненный цикл» всё ещё нужно проверить раздельно?

class SessionLifecycle with WidgetsBindingObserver {
  @override
  void didChangeAppLifecycleState(AppLifecycleState state) {
    if (state == AppLifecycleState.inactive || state == AppLifecycleState.paused) {
      sessions.persistDraft();
    }
  }
}

// Контекст задания: анализ граничных входов.

Для «Жизненный цикл» ограничиться случаем «приостановка и уничтожение процесса», а остальные входы считать тем же классом отказа. Объединить «приостановка и уничтожение процесса» и «перезагрузка вкладки» в один тест «Жизненный цикл» с общим ожидаемым исходом. Автоматизировать обычный путь «Жизненный цикл», а случай «ограничение фоновой работы» оставить в ручном чек-листе выпуска. Задать самостоятельные ожидания для случаев: приостановка и уничтожение процесса, перезагрузка вкладки и ограничение фоновой работы. Проверить для «Жизненный цикл» только самый сложный случай «ограничение фоновой работы», считая остальные границы косвенно покрытыми.

Вопрос 13 из 30

На ревью просят не размножать проверки по вызывающему коду. Какое исправление для «Жизненный цикл» отвечает этому требованию?

class SessionLifecycle with WidgetsBindingObserver {
  @override
  void didChangeAppLifecycleState(AppLifecycleState state) {
    if (state == AppLifecycleState.inactive || state == AppLifecycleState.paused) {
      sessions.persistDraft();
    }
  }
}

// Контекст задания: выбор места исправления.

Скопировать защиту «Жизненный цикл» во все найденные места вызова и считать повторение единым исправлением. В решении «Жизненный цикл» перехватывать любое исключение и возвращать нейтральное значение без указания причины. Сохранять необходимое состояние и уметь повторно инициализировать ресурсы после возврата или нового процесса. Добавить в «Жизненный цикл» специальный флаг только для одного экрана или сервиса, сохранив общий контракт. Ослабить правило «Жизненный цикл» для случая «ограничение фоновой работы», чтобы спорный вход проходил как допустимый.

Вопрос 14 из 30

Перед обновлением зависимости нужно защитить исправление «Жизненный цикл». Какая проверка подходит лучше всего?

Проверять «Жизненный цикл» на одной текущей реализации и не фиксировать внешний договор. Проверка «Жизненный цикл» в этом варианте зависит от текущего устройства реализации. Проверить уход в фон, уничтожение процесса, возврат и перезагрузку веб-страницы. В регрессии «Жизненный цикл» сравнивать текст журналов вместо возвращаемого результата и состояния. В тесте «Жизненный цикл» подменить спорный механизм готовым успешным ответом ради стабильности. После операции «Жизненный цикл» проверять приватные поля и точное число внутренних вызовов.

Вопрос 15 из 30

Какой контракт по теме «Жизненный цикл» отделяет наблюдаемое поведение от внутренних шагов?

Перед вызовом «Жизненный цикл» заставить клиента повторять валидацию, не описывая отказ самого компонента. В договоре «Жизненный цикл» описать только успешный путь, оставив спорные входы на усмотрение реализации. Из «Жизненный цикл» возвращать строку или `null`, а смысл результата разбирать отдельно в каждом клиенте. Общий код не должен предполагать одинаковый жизненный цикл Android, iOS и Web. Включить в договор «Жизненный цикл» конкретный способ хранения состояния вместо наблюдаемого результата.

Вопрос 16 из 30

Какой вариант правки убирает источник дефекта «Единый интерфейс» и не заставляет клиентов дублировать защиту?

abstract interface class BackgroundSync {
  bool get isAvailable;
  Future<SyncResult> schedule(SyncRequest request);
}

// Контекст задания: выбор места исправления.

В решении «Единый интерфейс» перехватывать любое исключение и возвращать нейтральное значение без указания причины. Скрыть механические различия за совместимым интерфейсом, сохранив явный результат «возможность недоступна». Добавить в «Единый интерфейс» специальный флаг только для одного экрана или сервиса, сохранив общий контракт. Скопировать защиту «Единый интерфейс» во все найденные места вызова и считать повторение единым исправлением. Оставить поведение «Единый интерфейс» прежним, но заменить сообщение об ошибке на более подробное.

Вопрос 17 из 30

Код проходит обычный сценарий. Какие проверки по теме «Единый интерфейс» нужны, чтобы разные граничные исходы не слились в один?

abstract interface class BackgroundSync {
  bool get isAvailable;
  Future<SyncResult> schedule(SyncRequest request);
}

// Контекст задания: анализ граничных входов.

Объединить «разная доступность API» и «неодинаковые гарантии фоновой работы» в один тест «Единый интерфейс» с общим ожидаемым исходом. Проверить для «Единый интерфейс» только самый сложный случай «разные форматы платформенной ошибки», считая остальные границы косвенно покрытыми. Автоматизировать обычный путь «Единый интерфейс», а случай «разные форматы платформенной ошибки» оставить в ручном чек-листе выпуска. Проверить независимо друг от друга: разная доступность API, неодинаковые гарантии фоновой работы и разные форматы платформенной ошибки. Во всех спорных входах «Единый интерфейс» проверять только отсутствие необработанного исключения, не сравнивая состояние.

Вопрос 18 из 30

Что в поведении этого кода гарантировано правилами темы «Единый интерфейс», а не случайно совпало в одном запуске?

abstract interface class BackgroundSync {
  bool get isAvailable;
  Future<SyncResult> schedule(SyncRequest request);
}

// Контекст задания: проверка семантики фрагмента.

Единый интерфейс скрывает механические различия, но не выдумывает одинаковые гарантии там, где платформы их не дают; ограничения отражаются в типах или возможностях. Порядок внутренних вызовов «Единый интерфейс» считать публичной гарантией, которую нельзя менять при рефакторинге. Вывод делают по поведению текущей реализации «Единый интерфейс» на обычном входе. Спорный результат «Единый интерфейс» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь. Случай «разные форматы платформенной ошибки» объявить внутренней деталью «Единый интерфейс», даже если клиент видит иной результат. Для «Единый интерфейс» считать случаи «разная доступность API, неодинаковые гарантии фоновой работы и разные форматы платформенной ошибки» эквивалентными, если программа не завершается аварийно.

Вопрос 19 из 30

Как сформулировать публичное обещание темы «Единый интерфейс», не привязывая клиента к конкретному классу?

Из «Единый интерфейс» возвращать строку или `null`, а смысл результата разбирать отдельно в каждом клиенте. Единый интерфейс должен унифицировать вызов, но не выдумывать одинаковые возможности и гарантии. В договоре «Единый интерфейс» описать только успешный путь, оставив спорные входы на усмотрение реализации. Перед вызовом «Единый интерфейс» заставить клиента повторять валидацию, не описывая отказ самого компонента. Включить в договор «Единый интерфейс» конкретный способ хранения состояния вместо наблюдаемого результата.

Вопрос 20 из 30

Перед обновлением зависимости нужно защитить исправление «Единый интерфейс». Какая проверка подходит лучше всего?

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

Вопрос 21 из 30

Текущая защита работает лишь в одном сценарии. Что следует изменить в самом решении по теме «Разбор отказов»?

void reportPlatformFailure(Object error, StackTrace stack) {
  diagnostics.record(
    error,
    stack,
    tags: {'platform': platform.name, 'osVersion': platform.version, 'buildMode': buildMode.name},
  );
}

// Контекст задания: выбор места исправления.

Скопировать защиту «Разбор отказов» во все найденные места вызова и считать повторение единым исправлением. Перенести проверку «Разбор отказов» в тестовый код, не меняя производственную реализацию. Изменение кажется безопасным, потому что обычный путь «Разбор отказов» остаётся прежним. Оставить поведение «Разбор отказов» прежним, но заменить сообщение об ошибке на более подробное. Скрыть сбой «Разбор отказов» автоматической повторной попыткой без ограничения числа запусков. Собирать контекст платформы и воспроизводить отказ на той же версии и стадии жизненного цикла.

Вопрос 22 из 30

Какое утверждение корректно связывает показанный код с семантикой темы «Разбор отказов»?

void reportPlatformFailure(Object error, StackTrace stack) {
  diagnostics.record(
    error,
    stack,
    tags: {'platform': platform.name, 'osVersion': platform.version, 'buildMode': buildMode.name},
  );
}

// Контекст задания: проверка семантики фрагмента.

Отказ разбирают по платформе, версии ОС, типу сборки и этапу жизненного цикла; сообщение «не работает на iOS» недостаточно для воспроизведения. В теме «Разбор отказов» отсутствие предупреждения анализатора считать гарантией для любого допустимого входа. Случай «этап жизненного цикла» объявить внутренней деталью «Разбор отказов», даже если клиент видит иной результат. Порядок внутренних вызовов «Разбор отказов» считать публичной гарантией, которую нельзя менять при рефакторинге. Спорный результат «Разбор отказов» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь.

Вопрос 23 из 30

Код проходит обычный сценарий. Какие проверки по теме «Разбор отказов» нужны, чтобы разные граничные исходы не слились в один?

void reportPlatformFailure(Object error, StackTrace stack) {
  diagnostics.record(
    error,
    stack,
    tags: {'platform': platform.name, 'osVersion': platform.version, 'buildMode': buildMode.name},
  );
}

// Контекст задания: анализ граничных входов.

Для «Разбор отказов» ограничиться случаем «одинаковый симптом на разных ОС», а остальные входы считать тем же классом отказа. Составить отдельные сценарии для границ: одинаковый симптом на разных ОС, версию платформы, режим сборки и этап жизненного цикла. Во всех спорных входах «Разбор отказов» проверять только отсутствие необработанного исключения, не сравнивая состояние. Проверить для «Разбор отказов» только самый сложный случай «этап жизненного цикла», считая остальные границы косвенно покрытыми. Объединить «одинаковый симптом на разных ОС» и «версию платформы» в один тест «Разбор отказов» с общим ожидаемым исходом.

Вопрос 24 из 30

Ручная проверка по теме «Разбор отказов» прошла. Как превратить её в полезную автоматическую регрессию?

Для «Разбор отказов» оставить только тест обычного пути, а исправленный случай считать закрытым ревью. В тесте «Разбор отказов» подменить спорный механизм готовым успешным ответом ради стабильности. Повторить один отказ на нескольких платформах и сравнить сообщения, состояние и этап возникновения. В регрессии «Разбор отказов» сравнивать текст журналов вместо возвращаемого результата и состояния. Запускать проверку «Разбор отказов» после выпуска на рабочем трафике, а не до изменения зависимости.

Вопрос 25 из 30

Как сформулировать публичное обещание темы «Разбор отказов», не привязывая клиента к конкретному классу?

Включить в договор «Разбор отказов» конкретный способ хранения состояния вместо наблюдаемого результата. Из «Разбор отказов» возвращать строку или `null`, а смысл результата разбирать отдельно в каждом клиенте. Диагностика должна различать общую ошибку приложения и платформенную причину. В договоре «Разбор отказов» описать только успешный путь, оставив спорные входы на усмотрение реализации. Перед вызовом «Разбор отказов» заставить клиента повторять валидацию, не описывая отказ самого компонента.

Вопрос 26 из 30

Для показанного решения написали один тест на успех. Какой набор граничных сценариев по теме «Восстановление системы» должен появиться рядом?

Future<void> restoreApplication() async {
  await plugins.initializeOnce();
  final draft = await drafts.loadLatest();
  await router.restore(draft?.route);
  await pendingOperations.resumeIdempotently();
}

// Контекст задания: анализ граничных входов.

Проверить для «Восстановление системы» только самый сложный случай «частично сохранённое состояние», считая остальные границы косвенно покрытыми. Не объединять в один исход следующие случаи: повторная инициализация плагина, восстановление подписок, потеря процесса и частично сохранённое состояние. Для «Восстановление системы» ограничиться случаем «повторная инициализация плагина», а остальные входы считать тем же классом отказа. Объединить «повторная инициализация плагина» и «восстановление подписок» в один тест «Восстановление системы» с общим ожидаемым исходом. Автоматизировать обычный путь «Восстановление системы», а случай «частично сохранённое состояние» оставить в ручном чек-листе выпуска.

Вопрос 27 из 30

Текущая защита работает лишь в одном сценарии. Что следует изменить в самом решении по теме «Восстановление системы»?

Future<void> restoreApplication() async {
  await plugins.initializeOnce();
  final draft = await drafts.loadLatest();
  await router.restore(draft?.route);
  await pendingOperations.resumeIdempotently();
}

// Контекст задания: выбор места исправления.

Оставить поведение «Восстановление системы» прежним, но заменить сообщение об ошибке на более подробное. Перенести проверку «Восстановление системы» в тестовый код, не меняя производственную реализацию. Скрыть сбой «Восстановление системы» автоматической повторной попыткой без ограничения числа запусков. Скопировать защиту «Восстановление системы» во все найденные места вызова и считать повторение единым исправлением. Сделать инициализацию идемпотентной и восстанавливать только проверенное сериализуемое состояние.

Вопрос 28 из 30

Какое утверждение корректно связывает показанный код с семантикой темы «Восстановление системы»?

Future<void> restoreApplication() async {
  await plugins.initializeOnce();
  final draft = await drafts.loadLatest();
  await router.restore(draft?.route);
  await pendingOperations.resumeIdempotently();
}

// Контекст задания: проверка семантики фрагмента.

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

Вопрос 29 из 30

Две реализации решают задачу «Восстановление системы» по-разному. Какое требование делает их взаимозаменяемыми для клиента?

Из «Восстановление системы» возвращать строку или `null`, а смысл результата разбирать отдельно в каждом клиенте. Включить в договор «Восстановление системы» конкретный способ хранения состояния вместо наблюдаемого результата. В договоре «Восстановление системы» описать только успешный путь, оставив спорные входы на усмотрение реализации. После возврата система должна прийти к согласованному состоянию независимо от того, сохранился ли прежний процесс. Перед вызовом «Восстановление системы» заставить клиента повторять валидацию, не описывая отказ самого компонента.

Вопрос 30 из 30

Ручная проверка по теме «Восстановление системы» прошла. Как превратить её в полезную автоматическую регрессию?

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