Future и async/await — бесплатный тест онлайн

Вопрос 1 из 20

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

Future<int> calculate() {
  return Future<int>(() {
    print('worker');
    return 6 * 7;
  });
}
Future<void> main() async {
  print('start');
  print(await calculate());
}

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

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

Вопрос 2 из 20

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

Future<int> calculate() {
  return Future<int>(() {
    print('worker');
    return 6 * 7;
  });
}
Future<void> main() async {
  print('start');
  print(await calculate());
}

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

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

Вопрос 3 из 20

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

Future<int> calculate() {
  return Future<int>(() {
    print('worker');
    return 6 * 7;
  });
}
Future<void> main() async {
  print('start');
  print(await calculate());
}

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

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

Вопрос 4 из 20

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

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

Вопрос 5 из 20

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

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

Вопрос 6 из 20

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

Future<void> main() async {
  print('A');
  await Future<void>.delayed(Duration.zero);
  print('B');
}

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

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

Вопрос 7 из 20

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

Future<void> main() async {
  print('A');
  await Future<void>.delayed(Duration.zero);
  print('B');
}

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

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

Вопрос 8 из 20

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

Future<void> main() async {
  print('A');
  await Future<void>.delayed(Duration.zero);
  print('B');
}

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

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

Вопрос 9 из 20

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

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

Вопрос 10 из 20

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

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

Вопрос 11 из 20

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

Future<void> loadAll() async {
  final userFuture = loadUser();
  final feedFuture = loadFeed();
  final results = await Future.wait([userFuture, feedFuture]);
  render(results);
}

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

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

Вопрос 12 из 20

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

Future<void> loadAll() async {
  final userFuture = loadUser();
  final feedFuture = loadFeed();
  final results = await Future.wait([userFuture, feedFuture]);
  render(results);
}

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

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

Вопрос 13 из 20

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

Future<void> loadAll() async {
  final userFuture = loadUser();
  final feedFuture = loadFeed();
  final results = await Future.wait([userFuture, feedFuture]);
  render(results);
}

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

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

Вопрос 14 из 20

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

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

Вопрос 15 из 20

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

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

Вопрос 16 из 20

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

Future<String> request() async {
  try {
    return await client.fetch();
  } on TimeoutException {
    return 'cached';
  }
}

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

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

Вопрос 17 из 20

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

Future<String> request() async {
  try {
    return await client.fetch();
  } on TimeoutException {
    return 'cached';
  }
}

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

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

Вопрос 18 из 20

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

Future<String> request() async {
  try {
    return await client.fetch();
  } on TimeoutException {
    return 'cached';
  }
}

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

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

Вопрос 19 из 20

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

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

Вопрос 20 из 20

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

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