Обобщения и расширения типов — бесплатный тест онлайн

Вопрос 1 из 20

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

T firstOr<T>(List<T> values, T fallback) {
  return values.isEmpty ? fallback : values.first;
}
void main() => print(firstOr<int>([], 8));

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

Случай «пустая коллекция» объявить внутренней деталью «Параметры типов», даже если клиент видит иной результат. Порядок внутренних вызовов «Параметры типов» считать публичной гарантией, которую нельзя менять при рефакторинге. Параметр типа сохраняет связь входа и выхода, которую потерял бы `dynamic`; `List<T>` и `T Function(T)` позволяют анализатору проверять эту связь. В теме «Параметры типов» отсутствие предупреждения анализатора считать гарантией для любого допустимого входа. Спорный результат «Параметры типов» должен разбирать вызывающий код, поскольку компонент отвечает лишь за обычный путь.

Вопрос 2 из 20

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

T firstOr<T>(List<T> values, T fallback) {
  return values.isEmpty ? fallback : values.first;
}
void main() => print(firstOr<int>([], 8));

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

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

Вопрос 3 из 20

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

T firstOr<T>(List<T> values, T fallback) {
  return values.isEmpty ? fallback : values.first;
}
void main() => print(firstOr<int>([], 8));

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

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

Вопрос 4 из 20

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

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

Вопрос 5 из 20

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

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

Вопрос 6 из 20

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

num sumValues<T extends num>(Iterable<T> values) {
  return values.fold<num>(0, (sum, value) => sum + value);
}
void main() => print(sumValues([1, 2.5, 3]));

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

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

Вопрос 7 из 20

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

num sumValues<T extends num>(Iterable<T> values) {
  return values.fold<num>(0, (sum, value) => sum + value);
}
void main() => print(sumValues([1, 2.5, 3]));

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

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

Вопрос 8 из 20

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

num sumValues<T extends num>(Iterable<T> values) {
  return values.fold<num>(0, (sum, value) => sum + value);
}
void main() => print(sumValues([1, 2.5, 3]));

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

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

Вопрос 9 из 20

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

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

Вопрос 10 из 20

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

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

Вопрос 11 из 20

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

extension SafeFirst<T> on Iterable<T> {
  T? get firstOrNull {
    final it = iterator;
    return it.moveNext() ? it.current : null;
  }
}
void main() => print(<int>[].firstOrNull);

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

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

Вопрос 12 из 20

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

extension SafeFirst<T> on Iterable<T> {
  T? get firstOrNull {
    final it = iterator;
    return it.moveNext() ? it.current : null;
  }
}
void main() => print(<int>[].firstOrNull);

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

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

Вопрос 13 из 20

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

extension SafeFirst<T> on Iterable<T> {
  T? get firstOrNull {
    final it = iterator;
    return it.moveNext() ? it.current : null;
  }
}
void main() => print(<int>[].firstOrNull);

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

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

Вопрос 14 из 20

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

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

Вопрос 15 из 20

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

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

Вопрос 16 из 20

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

abstract interface class Decoder<T> {
  T decode(Object? raw);
}

T load<T>(Object? raw, Decoder<T> decoder) {
  return decoder.decode(raw);
}

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

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

Вопрос 17 из 20

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

abstract interface class Decoder<T> {
  T decode(Object? raw);
}

T load<T>(Object? raw, Decoder<T> decoder) {
  return decoder.decode(raw);
}

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

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

Вопрос 18 из 20

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

abstract interface class Decoder<T> {
  T decode(Object? raw);
}

T load<T>(Object? raw, Decoder<T> decoder) {
  return decoder.decode(raw);
}

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

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

Вопрос 19 из 20

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

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

Вопрос 20 из 20

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

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