Диагностика аварий и утечек — бесплатный тест онлайн

Вопрос 1 из 30

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

Future<void> refresh() async {
  try {
    await repository.refresh();
  } catch (error, stack) {
    Error.throwWithStackTrace(RefreshFailed(error), stack);
  }
}

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

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

Вопрос 2 из 30

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

Future<void> refresh() async {
  try {
    await repository.refresh();
  } catch (error, stack) {
    Error.throwWithStackTrace(RefreshFailed(error), stack);
  }
}

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

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

Вопрос 3 из 30

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

Future<void> refresh() async {
  try {
    await repository.refresh();
  } catch (error, stack) {
    Error.throwWithStackTrace(RefreshFailed(error), stack);
  }
}

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

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

Вопрос 4 из 30

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

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

Вопрос 5 из 30

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

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

Вопрос 6 из 30

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

void reportCrash(Object error, StackTrace stack) {
  crashes.record(
    error,
    stack,
    tags: {'appVersion': build.version, 'platform': platform.name, 'screen': route.name},
  );
}

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

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

Вопрос 7 из 30

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

void reportCrash(Object error, StackTrace stack) {
  crashes.record(
    error,
    stack,
    tags: {'appVersion': build.version, 'platform': platform.name, 'screen': route.name},
  );
}

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

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

Вопрос 8 из 30

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

void reportCrash(Object error, StackTrace stack) {
  crashes.record(
    error,
    stack,
    tags: {'appVersion': build.version, 'platform': platform.name, 'screen': route.name},
  );
}

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

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

Вопрос 9 из 30

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

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

Вопрос 10 из 30

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

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

Вопрос 11 из 30

Обычный путь в коде зелёный. Как построить проверку «Удержание объектов», чтобы не пропустить различия между отказами?

class _SearchState extends State<Search> {
  Timer? debounce;
  StreamSubscription<Result>? subscription;

  @override
  void dispose() {
    debounce?.cancel();
    subscription?.cancel();
    super.dispose();
  }
}

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

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

Вопрос 12 из 30

Что здесь следует считать правилом «Удержание объектов», а что — лишь деталью текущей реализации?

class _SearchState extends State<Search> {
  Timer? debounce;
  StreamSubscription<Result>? subscription;

  @override
  void dispose() {
    debounce?.cancel();
    subscription?.cancel();
    super.dispose();
  }
}

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

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

Вопрос 13 из 30

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

class _SearchState extends State<Search> {
  Timer? debounce;
  StreamSubscription<Result>? subscription;

  @override
  void dispose() {
    debounce?.cancel();
    subscription?.cancel();
    super.dispose();
  }
}

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

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

Вопрос 14 из 30

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

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

Вопрос 15 из 30

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

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

Вопрос 16 из 30

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

Future<void> reproduce() async {
  final repository = InMemoryRepository(seed: failingSeed);
  final service = SearchService(repository);
  await service.search('a');
  await service.search('ab');
  await service.search('abc');
}

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

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

Вопрос 17 из 30

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

Future<void> reproduce() async {
  final repository = InMemoryRepository(seed: failingSeed);
  final service = SearchService(repository);
  await service.search('a');
  await service.search('ab');
  await service.search('abc');
}

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

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

Вопрос 18 из 30

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

Future<void> reproduce() async {
  final repository = InMemoryRepository(seed: failingSeed);
  final service = SearchService(repository);
  await service.search('a');
  await service.search('ab');
  await service.search('abc');
}

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

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

Вопрос 19 из 30

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

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

Вопрос 20 из 30

Какая регрессия для «Минимальный пример» будет падать на старом дефекте и не ломаться от безопасной перестройки кода?

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

Вопрос 21 из 30

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

final class NativeBuffer implements Finalizable {
  NativeBuffer(this.pointer, this.length) {
    _finalizer.attach(this, pointer.cast(), detach: this);
  }
  final Pointer<Uint8> pointer;
  final int length;
  void dispose() => _finalizer.detach(this);
}

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

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

Вопрос 22 из 30

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

final class NativeBuffer implements Finalizable {
  NativeBuffer(this.pointer, this.length) {
    _finalizer.attach(this, pointer.cast(), detach: this);
  }
  final Pointer<Uint8> pointer;
  final int length;
  void dispose() => _finalizer.detach(this);
}

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

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

Вопрос 23 из 30

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

final class NativeBuffer implements Finalizable {
  NativeBuffer(this.pointer, this.length) {
    _finalizer.attach(this, pointer.cast(), detach: this);
  }
  final Pointer<Uint8> pointer;
  final int length;
  void dispose() => _finalizer.detach(this);
}

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

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

Вопрос 24 из 30

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

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

Вопрос 25 из 30

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

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

Вопрос 26 из 30

Локальная заплатка помогла только одному клиенту этого кода. Какая правка устраняет причину в теме «Масштабирование решения»?

String crashFingerprint(CrashEvent event) {
  final topFrames = event.stack.frames.where((f) => f.package == 'client_app').take(5);
  return sha256.convert(utf8.encode('${event.errorType}|${topFrames.join('|')}')).toString();
}

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

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

Вопрос 27 из 30

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

String crashFingerprint(CrashEvent event) {
  final topFrames = event.stack.frames.where((f) => f.package == 'client_app').take(5);
  return sha256.convert(utf8.encode('${event.errorType}|${topFrames.join('|')}')).toString();
}

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

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

Вопрос 28 из 30

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

String crashFingerprint(CrashEvent event) {
  final topFrames = event.stack.frames.where((f) => f.package == 'client_app').take(5);
  return sha256.convert(utf8.encode('${event.errorType}|${topFrames.join('|')}')).toString();
}

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

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

Вопрос 29 из 30

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

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

Вопрос 30 из 30

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

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