Flutter: дерево виджетов и жизненный цикл — бесплатный тест онлайн

Вопрос 1 из 25

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

class UserName extends StatelessWidget {
  const UserName({super.key, required this.user});
  final User user;

  @override
  Widget build(BuildContext context) {
    return Text(user.displayName, style: Theme.of(context).textTheme.titleMedium);
  }
}

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

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

Вопрос 2 из 25

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

class UserName extends StatelessWidget {
  const UserName({super.key, required this.user});
  final User user;

  @override
  Widget build(BuildContext context) {
    return Text(user.displayName, style: Theme.of(context).textTheme.titleMedium);
  }
}

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

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

Вопрос 3 из 25

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

class UserName extends StatelessWidget {
  const UserName({super.key, required this.user});
  final User user;

  @override
  Widget build(BuildContext context) {
    return Text(user.displayName, style: Theme.of(context).textTheme.titleMedium);
  }
}

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

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

Вопрос 4 из 25

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

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

Вопрос 5 из 25

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

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

Вопрос 6 из 25

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

class _ProfilePaneState extends State<ProfilePane> {
  late Future<Profile> _profile;

  @override
  void initState() {
    super.initState();
    _profile = api.load(widget.userId);
  }

  @override
  void didUpdateWidget(covariant ProfilePane oldWidget) {
    super.didUpdateWidget(oldWidget);
    if (oldWidget.userId != widget.userId) _profile = api.load(widget.userId);
  }
}

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

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

Вопрос 7 из 25

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

class _ProfilePaneState extends State<ProfilePane> {
  late Future<Profile> _profile;

  @override
  void initState() {
    super.initState();
    _profile = api.load(widget.userId);
  }

  @override
  void didUpdateWidget(covariant ProfilePane oldWidget) {
    super.didUpdateWidget(oldWidget);
    if (oldWidget.userId != widget.userId) _profile = api.load(widget.userId);
  }
}

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

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

Вопрос 8 из 25

Какой вариант правки убирает источник дефекта «Состояние StatefulWidget» и не заставляет клиентов дублировать защиту?

class _ProfilePaneState extends State<ProfilePane> {
  late Future<Profile> _profile;

  @override
  void initState() {
    super.initState();
    _profile = api.load(widget.userId);
  }

  @override
  void didUpdateWidget(covariant ProfilePane oldWidget) {
    super.didUpdateWidget(oldWidget);
    if (oldWidget.userId != widget.userId) _profile = api.load(widget.userId);
  }
}

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

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

Вопрос 9 из 25

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

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

Вопрос 10 из 25

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

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

Вопрос 11 из 25

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

Future<void> save(BuildContext context) async {
  final result = await repository.save();
  if (!context.mounted) return;
  ScaffoldMessenger.of(context).showSnackBar(SnackBar(content: Text(result.message)));
}

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

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

Вопрос 12 из 25

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

Future<void> save(BuildContext context) async {
  final result = await repository.save();
  if (!context.mounted) return;
  ScaffoldMessenger.of(context).showSnackBar(SnackBar(content: Text(result.message)));
}

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

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

Вопрос 13 из 25

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

Future<void> save(BuildContext context) async {
  final result = await repository.save();
  if (!context.mounted) return;
  ScaffoldMessenger.of(context).showSnackBar(SnackBar(content: Text(result.message)));
}

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

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

Вопрос 14 из 25

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

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

Вопрос 15 из 25

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

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

Вопрос 16 из 25

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

class CartTotal extends StatelessWidget {
  const CartTotal({super.key, required this.total});
  final ValueListenable<Money> total;

  @override
  Widget build(BuildContext context) => ValueListenableBuilder(
    valueListenable: total,
    builder: (_, value, __) => Text(value.format()),
  );
}

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

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

Вопрос 17 из 25

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

class CartTotal extends StatelessWidget {
  const CartTotal({super.key, required this.total});
  final ValueListenable<Money> total;

  @override
  Widget build(BuildContext context) => ValueListenableBuilder(
    valueListenable: total,
    builder: (_, value, __) => Text(value.format()),
  );
}

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

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

Вопрос 18 из 25

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

class CartTotal extends StatelessWidget {
  const CartTotal({super.key, required this.total});
  final ValueListenable<Money> total;

  @override
  Widget build(BuildContext context) => ValueListenableBuilder(
    valueListenable: total,
    builder: (_, value, __) => Text(value.format()),
  );
}

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

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

Вопрос 19 из 25

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

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

Вопрос 20 из 25

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

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

Вопрос 21 из 25

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

Widget buildAdaptiveButton(BuildContext context) {
  final platform = Theme.of(context).platform;
  return switch (platform) {
    TargetPlatform.iOS || TargetPlatform.macOS => CupertinoButton(onPressed: save, child: const Text('Save')),
    _ => FilledButton(onPressed: save, child: const Text('Save')),
  };
}

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

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

Вопрос 22 из 25

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

Widget buildAdaptiveButton(BuildContext context) {
  final platform = Theme.of(context).platform;
  return switch (platform) {
    TargetPlatform.iOS || TargetPlatform.macOS => CupertinoButton(onPressed: save, child: const Text('Save')),
    _ => FilledButton(onPressed: save, child: const Text('Save')),
  };
}

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

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

Вопрос 23 из 25

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

Widget buildAdaptiveButton(BuildContext context) {
  final platform = Theme.of(context).platform;
  return switch (platform) {
    TargetPlatform.iOS || TargetPlatform.macOS => CupertinoButton(onPressed: save, child: const Text('Save')),
    _ => FilledButton(onPressed: save, child: const Text('Save')),
  };
}

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

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

Вопрос 24 из 25

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

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

Вопрос 25 из 25

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

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