Навигация и маршруты Flutter — бесплатный тест онлайн

Вопрос 1 из 25

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

Future<void> editOrder(BuildContext context, OrderId id) async {
  final changed = await Navigator.of(context).push<bool>(
    MaterialPageRoute(builder: (_) => OrderPage(id: id)),
  );
  if (changed == true && context.mounted) refresh(context);
}

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

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

Вопрос 2 из 25

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

Future<void> editOrder(BuildContext context, OrderId id) async {
  final changed = await Navigator.of(context).push<bool>(
    MaterialPageRoute(builder: (_) => OrderPage(id: id)),
  );
  if (changed == true && context.mounted) refresh(context);
}

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

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

Вопрос 3 из 25

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

Future<void> editOrder(BuildContext context, OrderId id) async {
  final changed = await Navigator.of(context).push<bool>(
    MaterialPageRoute(builder: (_) => OrderPage(id: id)),
  );
  if (changed == true && context.mounted) refresh(context);
}

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

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

Вопрос 4 из 25

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

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

Вопрос 5 из 25

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

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

Вопрос 6 из 25

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

Route<dynamic> onGenerateRoute(RouteSettings settings) {
  final uri = Uri.parse(settings.name ?? '/');
  if (uri.pathSegments case ['orders', final rawId]) {
    final id = OrderId.tryParse(rawId);
    return id == null ? invalidRoute() : orderRoute(id);
  }
  return notFoundRoute();
}

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

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

Вопрос 7 из 25

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

Route<dynamic> onGenerateRoute(RouteSettings settings) {
  final uri = Uri.parse(settings.name ?? '/');
  if (uri.pathSegments case ['orders', final rawId]) {
    final id = OrderId.tryParse(rawId);
    return id == null ? invalidRoute() : orderRoute(id);
  }
  return notFoundRoute();
}

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

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

Вопрос 8 из 25

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

Route<dynamic> onGenerateRoute(RouteSettings settings) {
  final uri = Uri.parse(settings.name ?? '/');
  if (uri.pathSegments case ['orders', final rawId]) {
    final id = OrderId.tryParse(rawId);
    return id == null ? invalidRoute() : orderRoute(id);
  }
  return notFoundRoute();
}

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

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

Вопрос 9 из 25

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

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

Вопрос 10 из 25

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

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

Вопрос 11 из 25

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

final class OrderRouteArgs {
  const OrderRouteArgs({required this.id, required this.source});
  final OrderId id;
  final AnalyticsSource source;
}

final args = ModalRoute.of(context)!.settings.arguments as OrderRouteArgs;

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

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

Вопрос 12 из 25

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

final class OrderRouteArgs {
  const OrderRouteArgs({required this.id, required this.source});
  final OrderId id;
  final AnalyticsSource source;
}

final args = ModalRoute.of(context)!.settings.arguments as OrderRouteArgs;

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

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

Вопрос 13 из 25

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

final class OrderRouteArgs {
  const OrderRouteArgs({required this.id, required this.source});
  final OrderId id;
  final AnalyticsSource source;
}

final args = ModalRoute.of(context)!.settings.arguments as OrderRouteArgs;

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

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

Вопрос 14 из 25

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

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

Вопрос 15 из 25

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

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

Вопрос 16 из 25

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

class RestorableOrderId extends RestorableValue<String?> {
  @override String? createDefaultValue() => null;
  @override void didUpdateValue(String? oldValue) => notifyListeners();
  @override String? fromPrimitives(Object? data) => data as String?;
  @override Object? toPrimitives() => value;
}

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

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

Вопрос 17 из 25

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

class RestorableOrderId extends RestorableValue<String?> {
  @override String? createDefaultValue() => null;
  @override void didUpdateValue(String? oldValue) => notifyListeners();
  @override String? fromPrimitives(Object? data) => data as String?;
  @override Object? toPrimitives() => value;
}

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

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

Вопрос 18 из 25

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

class RestorableOrderId extends RestorableValue<String?> {
  @override String? createDefaultValue() => null;
  @override void didUpdateValue(String? oldValue) => notifyListeners();
  @override String? fromPrimitives(Object? data) => data as String?;
  @override Object? toPrimitives() => value;
}

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

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

Вопрос 19 из 25

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

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

Вопрос 20 из 25

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

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

Вопрос 21 из 25

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

Future<Route<void>> secureOrderRoute(String rawId) async {
  final id = OrderId.tryParse(rawId);
  if (id == null) return invalidRoute();
  if (!await permissions.canRead(id)) return forbiddenRoute();
  return MaterialPageRoute(builder: (_) => OrderPage(id: id));
}

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

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

Вопрос 22 из 25

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

Future<Route<void>> secureOrderRoute(String rawId) async {
  final id = OrderId.tryParse(rawId);
  if (id == null) return invalidRoute();
  if (!await permissions.canRead(id)) return forbiddenRoute();
  return MaterialPageRoute(builder: (_) => OrderPage(id: id));
}

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

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

Вопрос 23 из 25

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

Future<Route<void>> secureOrderRoute(String rawId) async {
  final id = OrderId.tryParse(rawId);
  if (id == null) return invalidRoute();
  if (!await permissions.canRead(id)) return forbiddenRoute();
  return MaterialPageRoute(builder: (_) => OrderPage(id: id));
}

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

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

Вопрос 24 из 25

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

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

Вопрос 25 из 25

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

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