JSON и сериализация моделей — бесплатный тест онлайн

Вопрос 1 из 25

Текущая защита работает лишь в одном сценарии. Что следует изменить в самом решении по теме «Ручное преобразование»?

final class Profile {
  const Profile({required this.id, required this.name, this.age});
  final String id;
  final String name;
  final int? age;

  factory Profile.fromJson(Map<String, Object?> json) {
    final id = json['id'];
    final name = json['name'];
    if (id is! String || name is! String) {
      throw const FormatException('invalid profile');
    }
    return Profile(id: id, name: name, age: json['age'] as int?);
  }
}

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

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

Вопрос 2 из 25

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

final class Profile {
  const Profile({required this.id, required this.name, this.age});
  final String id;
  final String name;
  final int? age;

  factory Profile.fromJson(Map<String, Object?> json) {
    final id = json['id'];
    final name = json['name'];
    if (id is! String || name is! String) {
      throw const FormatException('invalid profile');
    }
    return Profile(id: id, name: name, age: json['age'] as int?);
  }
}

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

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

Вопрос 3 из 25

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

final class Profile {
  const Profile({required this.id, required this.name, this.age});
  final String id;
  final String name;
  final int? age;

  factory Profile.fromJson(Map<String, Object?> json) {
    final id = json['id'];
    final name = json['name'];
    if (id is! String || name is! String) {
      throw const FormatException('invalid profile');
    }
    return Profile(id: id, name: name, age: json['age'] as int?);
  }
}

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

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

Вопрос 4 из 25

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

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

Вопрос 5 из 25

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

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

Вопрос 6 из 25

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

@JsonSerializable()
final class InvoiceDto {
  const InvoiceDto({required this.id, required this.total});
  final String id;
  final int total;

  factory InvoiceDto.fromJson(Map<String, dynamic> json) =>
      _$InvoiceDtoFromJson(json);
  Map<String, dynamic> toJson() => _$InvoiceDtoToJson(this);
}

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

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

Вопрос 7 из 25

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

@JsonSerializable()
final class InvoiceDto {
  const InvoiceDto({required this.id, required this.total});
  final String id;
  final int total;

  factory InvoiceDto.fromJson(Map<String, dynamic> json) =>
      _$InvoiceDtoFromJson(json);
  Map<String, dynamic> toJson() => _$InvoiceDtoToJson(this);
}

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

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

Вопрос 8 из 25

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

@JsonSerializable()
final class InvoiceDto {
  const InvoiceDto({required this.id, required this.total});
  final String id;
  final int total;

  factory InvoiceDto.fromJson(Map<String, dynamic> json) =>
      _$InvoiceDtoFromJson(json);
  Map<String, dynamic> toJson() => _$InvoiceDtoToJson(this);
}

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

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

Вопрос 9 из 25

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

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

Вопрос 10 из 25

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

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

Вопрос 11 из 25

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

final class UserDto {
  const UserDto({required this.id, this.nickname});
  final String id;
  final String? nickname;

  factory UserDto.fromJson(Map<String, Object?> json) {
    if (!json.containsKey('id')) throw const FormatException('id missing');
    return UserDto(id: json['id'] as String, nickname: json['nickname'] as String?);
  }
}

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

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

Вопрос 12 из 25

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

final class UserDto {
  const UserDto({required this.id, this.nickname});
  final String id;
  final String? nickname;

  factory UserDto.fromJson(Map<String, Object?> json) {
    if (!json.containsKey('id')) throw const FormatException('id missing');
    return UserDto(id: json['id'] as String, nickname: json['nickname'] as String?);
  }
}

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

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

Вопрос 13 из 25

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

final class UserDto {
  const UserDto({required this.id, this.nickname});
  final String id;
  final String? nickname;

  factory UserDto.fromJson(Map<String, Object?> json) {
    if (!json.containsKey('id')) throw const FormatException('id missing');
    return UserDto(id: json['id'] as String, nickname: json['nickname'] as String?);
  }
}

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

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

Вопрос 14 из 25

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

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

Вопрос 15 из 25

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

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

Вопрос 16 из 25

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

Map<String, Object?> migratePayload(Map<String, Object?> source) {
  final version = source['schemaVersion'] as int? ?? 1;
  return switch (version) {
    1 => {...source, 'displayName': source['name'], 'schemaVersion': 2},
    2 => source,
    _ => throw FormatException('unsupported schema $version'),
  };
}

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

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

Вопрос 17 из 25

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

Map<String, Object?> migratePayload(Map<String, Object?> source) {
  final version = source['schemaVersion'] as int? ?? 1;
  return switch (version) {
    1 => {...source, 'displayName': source['name'], 'schemaVersion': 2},
    2 => source,
    _ => throw FormatException('unsupported schema $version'),
  };
}

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

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

Вопрос 18 из 25

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

Map<String, Object?> migratePayload(Map<String, Object?> source) {
  final version = source['schemaVersion'] as int? ?? 1;
  return switch (version) {
    1 => {...source, 'displayName': source['name'], 'schemaVersion': 2},
    2 => source,
    _ => throw FormatException('unsupported schema $version'),
  };
}

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

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

Вопрос 19 из 25

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

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

Вопрос 20 из 25

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

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

Вопрос 21 из 25

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

Profile decodeProfile(String body, Uri source) {
  try {
    final value = jsonDecode(body);
    if (value is! Map<String, Object?>) {
      throw const FormatException('object expected');
    }
    return Profile.fromJson(value);
  } on FormatException catch (error, stack) {
    Error.throwWithStackTrace(ProfileDecodeException(source, error), stack);
  }
}

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

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

Вопрос 22 из 25

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

Profile decodeProfile(String body, Uri source) {
  try {
    final value = jsonDecode(body);
    if (value is! Map<String, Object?>) {
      throw const FormatException('object expected');
    }
    return Profile.fromJson(value);
  } on FormatException catch (error, stack) {
    Error.throwWithStackTrace(ProfileDecodeException(source, error), stack);
  }
}

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

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

Вопрос 23 из 25

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

Profile decodeProfile(String body, Uri source) {
  try {
    final value = jsonDecode(body);
    if (value is! Map<String, Object?>) {
      throw const FormatException('object expected');
    }
    return Profile.fromJson(value);
  } on FormatException catch (error, stack) {
    Error.throwWithStackTrace(ProfileDecodeException(source, error), stack);
  }
}

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

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

Вопрос 24 из 25

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

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

Вопрос 25 из 25

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

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