Конкурентные вычисления и изоляты — бесплатный тест онлайн

Вопрос 1 из 30

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

List<List<int>> chunks(List<int> values, int size) {
  return [
    for (var start = 0; start < values.length; start += size)
      values.sublist(start, (start + size).clamp(0, values.length)),
  ];
}

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

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

Вопрос 2 из 30

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

List<List<int>> chunks(List<int> values, int size) {
  return [
    for (var start = 0; start < values.length; start += size)
      values.sublist(start, (start + size).clamp(0, values.length)),
  ];
}

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

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

Вопрос 3 из 30

Какой тезис о коде «Разбиение задачи» можно защитить без ссылки на удачный тестовый запуск?

List<List<int>> chunks(List<int> values, int size) {
  return [
    for (var start = 0; start < values.length; start += size)
      values.sublist(start, (start + size).clamp(0, values.length)),
  ];
}

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

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

Вопрос 4 из 30

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

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

Вопрос 5 из 30

После исправления темы «Разбиение задачи» нужен тест, который переживёт рефакторинг. Что следует закрепить?

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

Вопрос 6 из 30

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

Future<Uint8List> decodeInWorker(Uint8List bytes) async {
  final transferable = TransferableTypedData.fromList([bytes]);
  return Isolate.run(() => decode(transferable.materialize().asUint8List()));
}

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

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

Вопрос 7 из 30

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

Future<Uint8List> decodeInWorker(Uint8List bytes) async {
  final transferable = TransferableTypedData.fromList([bytes]);
  return Isolate.run(() => decode(transferable.materialize().asUint8List()));
}

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

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

Вопрос 8 из 30

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

Future<Uint8List> decodeInWorker(Uint8List bytes) async {
  final transferable = TransferableTypedData.fromList([bytes]);
  return Isolate.run(() => decode(transferable.materialize().asUint8List()));
}

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

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

Вопрос 9 из 30

Что добавить в набор тестов, чтобы ошибка по теме «Передача больших данных» не вернулась незаметно?

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

Вопрос 10 из 30

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

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

Вопрос 11 из 30

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

final class WorkerPool {
  WorkerPool(this.size);
  final int size;
  final Queue<Job> pending = Queue();
  final Set<Worker> busy = {};

  void submit(Job job) {
    pending.add(job);
    schedule();
  }
}

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

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

Вопрос 12 из 30

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

final class WorkerPool {
  WorkerPool(this.size);
  final int size;
  final Queue<Job> pending = Queue();
  final Set<Worker> busy = {};

  void submit(Job job) {
    pending.add(job);
    schedule();
  }
}

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

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

Вопрос 13 из 30

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

final class WorkerPool {
  WorkerPool(this.size);
  final int size;
  final Queue<Job> pending = Queue();
  final Set<Worker> busy = {};

  void submit(Job job) {
    pending.add(job);
    schedule();
  }
}

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

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

Вопрос 14 из 30

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

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

Вопрос 15 из 30

Что добавить в набор тестов, чтобы ошибка по теме «Пул исполнителей» не вернулась незаметно?

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

Вопрос 16 из 30

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

sealed class WorkerCommand { const WorkerCommand(); }
final class RunJob extends WorkerCommand { const RunJob(this.id, this.data); final int id; final Uint8List data; }
final class CancelJob extends WorkerCommand { const CancelJob(this.id); final int id; }

if (cancelled.contains(job.id)) return const JobResult.cancelled();

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

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

Вопрос 17 из 30

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

sealed class WorkerCommand { const WorkerCommand(); }
final class RunJob extends WorkerCommand { const RunJob(this.id, this.data); final int id; final Uint8List data; }
final class CancelJob extends WorkerCommand { const CancelJob(this.id); final int id; }

if (cancelled.contains(job.id)) return const JobResult.cancelled();

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

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

Вопрос 18 из 30

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

sealed class WorkerCommand { const WorkerCommand(); }
final class RunJob extends WorkerCommand { const RunJob(this.id, this.data); final int id; final Uint8List data; }
final class CancelJob extends WorkerCommand { const CancelJob(this.id); final int id; }

if (cancelled.contains(job.id)) return const JobResult.cancelled();

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

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

Вопрос 19 из 30

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

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

Вопрос 20 из 30

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

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

Вопрос 21 из 30

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

Future<Comparison> compareStrategies(List<int> input) async {
  final sequential = await measure(() async => calculate(input));
  final oneIsolate = await measure(() => Isolate.run(() => calculate(input)));
  final pooled = await measure(() => pool.calculate(input));
  return Comparison(sequential, oneIsolate, pooled);
}

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

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

Вопрос 22 из 30

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

Future<Comparison> compareStrategies(List<int> input) async {
  final sequential = await measure(() async => calculate(input));
  final oneIsolate = await measure(() => Isolate.run(() => calculate(input)));
  final pooled = await measure(() => pool.calculate(input));
  return Comparison(sequential, oneIsolate, pooled);
}

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

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

Вопрос 23 из 30

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

Future<Comparison> compareStrategies(List<int> input) async {
  final sequential = await measure(() async => calculate(input));
  final oneIsolate = await measure(() => Isolate.run(() => calculate(input)));
  final pooled = await measure(() => pool.calculate(input));
  return Comparison(sequential, oneIsolate, pooled);
}

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

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

Вопрос 24 из 30

Одна реализация темы «Профилирование решения» заменяется другой. Что внешний код вправе ожидать после замены?

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

Вопрос 25 из 30

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

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

Вопрос 26 из 30

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

Future<Thumbnail> loadThumbnail(Uri uri) async {
  final bytes = await http.readBytes(uri);       // asynchronous I/O
  return Isolate.run(() => decodeImage(bytes));  // CPU-bound decoding
}

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

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

Вопрос 27 из 30

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

Future<Thumbnail> loadThumbnail(Uri uri) async {
  final bytes = await http.readBytes(uri);       // asynchronous I/O
  return Isolate.run(() => decodeImage(bytes));  // CPU-bound decoding
}

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

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

Вопрос 28 из 30

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

Future<Thumbnail> loadThumbnail(Uri uri) async {
  final bytes = await http.readBytes(uri);       // asynchronous I/O
  return Isolate.run(() => decodeImage(bytes));  // CPU-bound decoding
}

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

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

Вопрос 29 из 30

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

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

Вопрос 30 из 30

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

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