Управление состоянием во Flutter — бесплатный тест онлайн

Вопрос 1 из 25

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

class _CounterState extends State<Counter> {
  int value = 0;

  void increment() => setState(() => value++);

  @override
  Widget build(BuildContext context) => TextButton(
    onPressed: increment,
    child: Text('$value'),
  );
}

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

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

Вопрос 2 из 25

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

class _CounterState extends State<Counter> {
  int value = 0;

  void increment() => setState(() => value++);

  @override
  Widget build(BuildContext context) => TextButton(
    onPressed: increment,
    child: Text('$value'),
  );
}

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

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

Вопрос 3 из 25

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

class _CounterState extends State<Counter> {
  int value = 0;

  void increment() => setState(() => value++);

  @override
  Widget build(BuildContext context) => TextButton(
    onPressed: increment,
    child: Text('$value'),
  );
}

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

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

Вопрос 4 из 25

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

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

Вопрос 5 из 25

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

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

Вопрос 6 из 25

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

final class CartModel extends ChangeNotifier {
  final List<Item> _items = [];
  List<Item> get items => List.unmodifiable(_items);

  void add(Item item) {
    _items.add(item);
    notifyListeners();
  }
}

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

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

Вопрос 7 из 25

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

final class CartModel extends ChangeNotifier {
  final List<Item> _items = [];
  List<Item> get items => List.unmodifiable(_items);

  void add(Item item) {
    _items.add(item);
    notifyListeners();
  }
}

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

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

Вопрос 8 из 25

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

final class CartModel extends ChangeNotifier {
  final List<Item> _items = [];
  List<Item> get items => List.unmodifiable(_items);

  void add(Item item) {
    _items.add(item);
    notifyListeners();
  }
}

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

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

Вопрос 9 из 25

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

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

Вопрос 10 из 25

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

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

Вопрос 11 из 25

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

Widget build(BuildContext context) {
  return StreamBuilder<SessionState>(
    stream: sessions.states,
    initialData: const SessionState.loading(),
    builder: (_, snapshot) => SessionView(state: snapshot.requireData),
  );
}

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

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

Вопрос 12 из 25

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

Widget build(BuildContext context) {
  return StreamBuilder<SessionState>(
    stream: sessions.states,
    initialData: const SessionState.loading(),
    builder: (_, snapshot) => SessionView(state: snapshot.requireData),
  );
}

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

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

Вопрос 13 из 25

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

Widget build(BuildContext context) {
  return StreamBuilder<SessionState>(
    stream: sessions.states,
    initialData: const SessionState.loading(),
    builder: (_, snapshot) => SessionView(state: snapshot.requireData),
  );
}

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

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

Вопрос 14 из 25

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

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

Вопрос 15 из 25

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

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

Вопрос 16 из 25

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

final class OrdersViewModel extends ChangeNotifier {
  OrdersViewModel(this.repository);
  final OrderRepository repository;
  OrdersState state = const OrdersState.loading();

  Future<void> reload() async {
    state = const OrdersState.loading();
    notifyListeners();
    state = await repository.load().then(OrdersState.data, onError: OrdersState.error);
    notifyListeners();
  }
}

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

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

Вопрос 17 из 25

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

final class OrdersViewModel extends ChangeNotifier {
  OrdersViewModel(this.repository);
  final OrderRepository repository;
  OrdersState state = const OrdersState.loading();

  Future<void> reload() async {
    state = const OrdersState.loading();
    notifyListeners();
    state = await repository.load().then(OrdersState.data, onError: OrdersState.error);
    notifyListeners();
  }
}

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

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

Вопрос 18 из 25

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

final class OrdersViewModel extends ChangeNotifier {
  OrdersViewModel(this.repository);
  final OrderRepository repository;
  OrdersState state = const OrdersState.loading();

  Future<void> reload() async {
    state = const OrdersState.loading();
    notifyListeners();
    state = await repository.load().then(OrdersState.data, onError: OrdersState.error);
    notifyListeners();
  }
}

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

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

Вопрос 19 из 25

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

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

Вопрос 20 из 25

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

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

Вопрос 21 из 25

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

sealed class LoadState<T> {
  const LoadState();
}
final class Loading<T> extends LoadState<T> { const Loading(); }
final class Data<T> extends LoadState<T> { const Data(this.value); final T value; }
final class Failed<T> extends LoadState<T> { const Failed(this.error); final Object error; }

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

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

Вопрос 22 из 25

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

sealed class LoadState<T> {
  const LoadState();
}
final class Loading<T> extends LoadState<T> { const Loading(); }
final class Data<T> extends LoadState<T> { const Data(this.value); final T value; }
final class Failed<T> extends LoadState<T> { const Failed(this.error); final Object error; }

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

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

Вопрос 23 из 25

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

sealed class LoadState<T> {
  const LoadState();
}
final class Loading<T> extends LoadState<T> { const Loading(); }
final class Data<T> extends LoadState<T> { const Data(this.value); final T value; }
final class Failed<T> extends LoadState<T> { const Failed(this.error); final Object error; }

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

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

Вопрос 24 из 25

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

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

Вопрос 25 из 25

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

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