DT Dart · 20 вопросов · ~55 мин · ⏱ Таймер 55:00 · Лёгкий ·

Условия, циклы и сопоставление шаблонов

Тест по теме «Условия, циклы и сопоставление шаблонов» охватывает «Ветвления», «Циклы», «Сопоставление с шаблонами» и «Управление выполнением». В 20 вопросах нужно читать код, различать граничные случаи, выбирать место исправления, формулировать внешний договор и проектировать регрессионную проверку. Заданий с фрагментами кода — 12; в каждом вопросе один правильный ответ из пяти.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На работу отведено 55 минут. В заданиях с кодом опирайтесь на показанный фрагмент и наблюдаемое поведение; в ситуационных — на публичный договор и последствия решения.

Вопрос 1 из 20

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

String grade(int score) => switch (score) {
  >= 90 => 'A',
  >= 75 => 'B',
  _ => 'C',
};
void main() => print(grade(82));

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

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

Вопрос 2 из 20

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

String grade(int score) => switch (score) {
  >= 90 => 'A',
  >= 75 => 'B',
  _ => 'C',
};
void main() => print(grade(82));

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

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

Вопрос 3 из 20

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

String grade(int score) => switch (score) {
  >= 90 => 'A',
  >= 75 => 'B',
  _ => 'C',
};
void main() => print(grade(82));

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

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

Вопрос 4 из 20

Две реализации решают задачу «Ветвления» по-разному. Какое требование делает их взаимозаменяемыми для клиента?

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

Вопрос 5 из 20

Ручная проверка по теме «Ветвления» прошла. Как превратить её в полезную автоматическую регрессию?

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

Вопрос 6 из 20

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

void main() {
  final values = <int>[2, 4, 6, 8];
  var sum = 0;
  for (var i = 0; i < values.length; i += 2) {
    sum += values[i];
  }
  print(sum);
}

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

Диапазон `for (var i = 0; i < n; i++)` не включает `n`; изменение коллекции во время обычного обхода часто нарушает контракт итератора. Для «Циклы» всегда заменять явную ошибку нейтральным значением: `null`, пустой коллекцией или нулём. Спорный результат «Циклы» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь. Случай «изменение коллекции во время обхода» объявить внутренней деталью «Циклы», даже если клиент видит иной результат. Порядок внутренних вызовов «Циклы» считать публичной гарантией, которую нельзя менять при рефакторинге.

Вопрос 7 из 20

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

void main() {
  final values = <int>[2, 4, 6, 8];
  var sum = 0;
  for (var i = 0; i < values.length; i += 2) {
    sum += values[i];
  }
  print(sum);
}

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

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

Вопрос 8 из 20

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

void main() {
  final values = <int>[2, 4, 6, 8];
  var sum = 0;
  for (var i = 0; i < values.length; i += 2) {
    sum += values[i];
  }
  print(sum);
}

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

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

Вопрос 9 из 20

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

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

Вопрос 10 из 20

Две реализации решают задачу «Циклы» по-разному. Какое требование делает их взаимозаменяемыми для клиента?

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

Вопрос 11 из 20

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

String describe(Object value) => switch (value) {
  (int x, int y) when x == y => 'diagonal $x',
  (int x, int y) => 'point ${x + y}',
  _ => 'other',
};
void main() => print(describe((3, 3)));

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

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

Вопрос 12 из 20

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

String describe(Object value) => switch (value) {
  (int x, int y) when x == y => 'diagonal $x',
  (int x, int y) => 'point ${x + y}',
  _ => 'other',
};
void main() => print(describe((3, 3)));

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

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

Вопрос 13 из 20

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

String describe(Object value) => switch (value) {
  (int x, int y) when x == y => 'diagonal $x',
  (int x, int y) => 'point ${x + y}',
  _ => 'other',
};
void main() => print(describe((3, 3)));

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

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

Вопрос 14 из 20

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

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

Вопрос 15 из 20

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

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

Вопрос 16 из 20

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

void main() {
outer:
  for (var row = 0; row < 3; row++) {
    for (var col = 0; col < 3; col++) {
      if (row + col == 2) continue outer;
      print('$row:$col');
    }
  }
}

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

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

Вопрос 17 из 20

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

void main() {
outer:
  for (var row = 0; row < 3; row++) {
    for (var col = 0; col < 3; col++) {
      if (row + col == 2) continue outer;
      print('$row:$col');
    }
  }
}

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

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

Вопрос 18 из 20

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

void main() {
outer:
  for (var row = 0; row < 3; row++) {
    for (var col = 0; col < 3; col++) {
      if (row + col == 2) continue outer;
      print('$row:$col');
    }
  }
}

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

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

Вопрос 19 из 20

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

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

Вопрос 20 из 20

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

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

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу