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

Вопрос 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» возвращать строку или `null`, а смысл результата разбирать отдельно в каждом клиенте. ChangeNotifier должен публиковать согласованные снимки и иметь явного владельца жизненного цикла. Перед вызовом «Состояние на ChangeNotifier» заставить клиента повторять валидацию, не описывая отказ самого компонента. В договоре «Состояние на ChangeNotifier» описать только успешный путь, оставив спорные входы на усмотрение реализации.

Вопрос 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();
  }
}

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

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

Вопрос 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`, а смысл результата разбирать отдельно в каждом клиенте. В договоре «Контроль состояния» описать только успешный путь, оставив спорные входы на усмотрение реализации.