Типы, переменные и null safety — бесплатный тест онлайн

Вопрос 1 из 20

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

void main() {
  var count = 3;
  final label = 'items';
  // count = 3.5; // анализатор отклонит
  print('$count $label');
}

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

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

Вопрос 2 из 20

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

void main() {
  var count = 3;
  final label = 'items';
  // count = 3.5; // анализатор отклонит
  print('$count $label');
}

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

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

Вопрос 3 из 20

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

void main() {
  var count = 3;
  final label = 'items';
  // count = 3.5; // анализатор отклонит
  print('$count $label');
}

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

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

Вопрос 4 из 20

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

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

Вопрос 5 из 20

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

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

Вопрос 6 из 20

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

int? read(bool ok) => ok ? 7 : null;
void main() {
  final value = read(false);
  final doubled = value == null ? 0 : value * 2;
  print(doubled);
}

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

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

Вопрос 7 из 20

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

int? read(bool ok) => ok ? 7 : null;
void main() {
  final value = read(false);
  final doubled = value == null ? 0 : value * 2;
  print(doubled);
}

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

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

Вопрос 8 из 20

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

int? read(bool ok) => ok ? 7 : null;
void main() {
  final value = read(false);
  final doubled = value == null ? 0 : value * 2;
  print(doubled);
}

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

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

Вопрос 9 из 20

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

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

Вопрос 10 из 20

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

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

Вопрос 11 из 20

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

void main() {
  String? name;
  name ??= 'guest';
  final length = name?.trim().length ?? 0;
  print('$name:$length');
}

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

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

Вопрос 12 из 20

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

void main() {
  String? name;
  name ??= 'guest';
  final length = name?.trim().length ?? 0;
  print('$name:$length');
}

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

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

Вопрос 13 из 20

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

void main() {
  String? name;
  name ??= 'guest';
  final length = name?.trim().length ?? 0;
  print('$name:$length');
}

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

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

Вопрос 14 из 20

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

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

Вопрос 15 из 20

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

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

Вопрос 16 из 20

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

class Session {
  late final String token;
  void open(String value) => token = value;
}
void main() {
  final s = Session();
  s.open('abc');
  print(s.token.length);
}

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

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

Вопрос 17 из 20

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

class Session {
  late final String token;
  void open(String value) => token = value;
}
void main() {
  final s = Session();
  s.open('abc');
  print(s.token.length);
}

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

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

Вопрос 18 из 20

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

class Session {
  late final String token;
  void open(String value) => token = value;
}
void main() {
  final s = Session();
  s.open('abc');
  print(s.token.length);
}

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

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

Вопрос 19 из 20

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

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

Вопрос 20 из 20

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

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