Списки, множества и отображения — бесплатный тест онлайн

Вопрос 1 из 20

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

void main() {
  final tags = <String>{'dart', 'flutter', 'dart'};
  final lengths = <String, int>{for (final t in tags) t: t.length};
  print('${tags.length}:${lengths['flutter']}');
}

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

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

Вопрос 2 из 20

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

void main() {
  final tags = <String>{'dart', 'flutter', 'dart'};
  final lengths = <String, int>{for (final t in tags) t: t.length};
  print('${tags.length}:${lengths['flutter']}');
}

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

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

Вопрос 3 из 20

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

void main() {
  final tags = <String>{'dart', 'flutter', 'dart'};
  final lengths = <String, int>{for (final t in tags) t: t.length};
  print('${tags.length}:${lengths['flutter']}');
}

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

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

Вопрос 4 из 20

Что должно оставаться неизменным при замене реализации темы «Коллекции»?

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

Вопрос 5 из 20

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

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

Вопрос 6 из 20

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

void main() {
  List<int>? extra = [3, 4];
  final values = <int>[1, 2, ...?extra, 5];
  extra[0] = 99;
  print(values);
}

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

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

Вопрос 7 из 20

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

void main() {
  List<int>? extra = [3, 4];
  final values = <int>[1, 2, ...?extra, 5];
  extra[0] = 99;
  print(values);
}

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

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

Вопрос 8 из 20

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

void main() {
  List<int>? extra = [3, 4];
  final values = <int>[1, 2, ...?extra, 5];
  extra[0] = 99;
  print(values);
}

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

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

Вопрос 9 из 20

Какой сценарий должен стать постоянной проверкой после исправления «Spread-оператор»?

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

Вопрос 10 из 20

Что должно оставаться неизменным при замене реализации темы «Spread-оператор»?

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

Вопрос 11 из 20

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

List<String> menu(bool admin, List<String> projects) => <String>[
  'home',
  if (admin) 'settings',
  for (final p in projects) 'project:$p',
];
void main() => print(menu(false, ['a', 'b']));

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

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

Вопрос 12 из 20

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

List<String> menu(bool admin, List<String> projects) => <String>[
  'home',
  if (admin) 'settings',
  for (final p in projects) 'project:$p',
];
void main() => print(menu(false, ['a', 'b']));

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

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

Вопрос 13 из 20

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

List<String> menu(bool admin, List<String> projects) => <String>[
  'home',
  if (admin) 'settings',
  for (final p in projects) 'project:$p',
];
void main() => print(menu(false, ['a', 'b']));

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

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

Вопрос 14 из 20

Какой контракт по теме «Условия и циклы внутри коллекций» отделяет наблюдаемое поведение от внутренних шагов?

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

Вопрос 15 из 20

Какой сценарий должен стать постоянной проверкой после исправления «Условия и циклы внутри коллекций»?

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

Вопрос 16 из 20

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

class Item { Item(this.value); int value; }
void main() {
  final source = [Item(1)];
  final view = List<Item>.unmodifiable(source);
  source.first.value = 9;
  print(view.first.value);
}

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

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

Вопрос 17 из 20

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

class Item { Item(this.value); int value; }
void main() {
  final source = [Item(1)];
  final view = List<Item>.unmodifiable(source);
  source.first.value = 9;
  print(view.first.value);
}

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

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

Вопрос 18 из 20

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

class Item { Item(this.value); int value; }
void main() {
  final source = [Item(1)];
  final view = List<Item>.unmodifiable(source);
  source.first.value = 9;
  print(view.first.value);
}

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

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

Вопрос 19 из 20

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

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

Вопрос 20 из 20

Какой контракт по теме «Неизменяемые данные» отделяет наблюдаемое поведение от внутренних шагов?

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