Изоляты и обмен сообщениями — бесплатный тест онлайн

Вопрос 1 из 25

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

Future<int> sumInWorker(List<int> values) async {
  final snapshot = List<int>.unmodifiable(values);
  return Isolate.run(() => snapshot.fold(0, (a, b) => a + b));
}

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

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

Вопрос 2 из 25

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

Future<int> sumInWorker(List<int> values) async {
  final snapshot = List<int>.unmodifiable(values);
  return Isolate.run(() => snapshot.fold(0, (a, b) => a + b));
}

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

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

Вопрос 3 из 25

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

Future<int> sumInWorker(List<int> values) async {
  final snapshot = List<int>.unmodifiable(values);
  return Isolate.run(() => snapshot.fold(0, (a, b) => a + b));
}

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

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

Вопрос 4 из 25

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

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

Вопрос 5 из 25

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

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

Вопрос 6 из 25

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

Future<int> requestSum(SendPort worker, List<int> values) async {
  final replies = ReceivePort();
  worker.send((values, replies.sendPort));
  try {
    return await replies.first as int;
  } finally {
    replies.close();
  }
}

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

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

Вопрос 7 из 25

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

Future<int> requestSum(SendPort worker, List<int> values) async {
  final replies = ReceivePort();
  worker.send((values, replies.sendPort));
  try {
    return await replies.first as int;
  } finally {
    replies.close();
  }
}

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

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

Вопрос 8 из 25

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

Future<int> requestSum(SendPort worker, List<int> values) async {
  final replies = ReceivePort();
  worker.send((values, replies.sendPort));
  try {
    return await replies.first as int;
  } finally {
    replies.close();
  }
}

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

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

Вопрос 9 из 25

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

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

Вопрос 10 из 25

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

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

Вопрос 11 из 25

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

Future<Report> buildReport(Uint8List bytes) {
  return Isolate.run(() {
    final rows = decodeRows(bytes);
    return Report.aggregate(rows);
  });
}

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

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

Вопрос 12 из 25

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

Future<Report> buildReport(Uint8List bytes) {
  return Isolate.run(() {
    final rows = decodeRows(bytes);
    return Report.aggregate(rows);
  });
}

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

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

Вопрос 13 из 25

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

Future<Report> buildReport(Uint8List bytes) {
  return Isolate.run(() {
    final rows = decodeRows(bytes);
    return Report.aggregate(rows);
  });
}

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

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

Вопрос 14 из 25

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

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

Вопрос 15 из 25

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

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

Вопрос 16 из 25

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

Future<void> stopWorker(Isolate worker, ReceivePort events) async {
  events.close();
  worker.kill(priority: Isolate.beforeNextEvent);
}

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

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

Вопрос 17 из 25

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

Future<void> stopWorker(Isolate worker, ReceivePort events) async {
  events.close();
  worker.kill(priority: Isolate.beforeNextEvent);
}

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

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

Вопрос 18 из 25

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

Future<void> stopWorker(Isolate worker, ReceivePort events) async {
  events.close();
  worker.kill(priority: Isolate.beforeNextEvent);
}

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

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

Вопрос 19 из 25

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

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

Вопрос 20 из 25

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

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

Вопрос 21 из 25

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

Future<WorkerHandle> spawnWorker() async {
  final ready = ReceivePort();
  final errors = ReceivePort();
  final exits = ReceivePort();
  final isolate = await Isolate.spawn(
    workerMain,
    ready.sendPort,
    onError: errors.sendPort,
    onExit: exits.sendPort,
  );
  return WorkerHandle(isolate, ready, errors, exits);
}

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

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

Вопрос 22 из 25

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

Future<WorkerHandle> spawnWorker() async {
  final ready = ReceivePort();
  final errors = ReceivePort();
  final exits = ReceivePort();
  final isolate = await Isolate.spawn(
    workerMain,
    ready.sendPort,
    onError: errors.sendPort,
    onExit: exits.sendPort,
  );
  return WorkerHandle(isolate, ready, errors, exits);
}

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

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

Вопрос 23 из 25

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

Future<WorkerHandle> spawnWorker() async {
  final ready = ReceivePort();
  final errors = ReceivePort();
  final exits = ReceivePort();
  final isolate = await Isolate.spawn(
    workerMain,
    ready.sendPort,
    onError: errors.sendPort,
    onExit: exits.sendPort,
  );
  return WorkerHandle(isolate, ready, errors, exits);
}

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

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

Вопрос 24 из 25

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

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

Вопрос 25 из 25

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

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