Наследование, интерфейсы и mixin — бесплатный тест онлайн

Вопрос 1 из 20

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

abstract class Store { Future<String?> read(String key); }
class MemoryStore extends Store {
  final _data = <String, String>{};
  @override Future<String?> read(String key) async => _data[key];
}

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

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

Вопрос 2 из 20

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

abstract class Store { Future<String?> read(String key); }
class MemoryStore extends Store {
  final _data = <String, String>{};
  @override Future<String?> read(String key) async => _data[key];
}

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

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

Вопрос 3 из 20

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

abstract class Store { Future<String?> read(String key); }
class MemoryStore extends Store {
  final _data = <String, String>{};
  @override Future<String?> read(String key) async => _data[key];
}

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

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

Вопрос 4 из 20

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

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

Вопрос 5 из 20

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

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

Вопрос 6 из 20

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

class Base { num convert(num x) => x; }
class Rounded extends Base {
  @override int convert(num x) => x.round();
}
void main() => print(Rounded().convert(2.6));

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

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

Вопрос 7 из 20

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

class Base { num convert(num x) => x; }
class Rounded extends Base {
  @override int convert(num x) => x.round();
}
void main() => print(Rounded().convert(2.6));

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

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

Вопрос 8 из 20

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

class Base { num convert(num x) => x; }
class Rounded extends Base {
  @override int convert(num x) => x.round();
}
void main() => print(Rounded().convert(2.6));

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

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

Вопрос 9 из 20

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

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

Вопрос 10 из 20

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

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

Вопрос 11 из 20

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

mixin Audited on Repository {
  void saveWithAudit(String value) {
    save(value);
    log('saved:$value');
  }
}
abstract class Repository { void save(String value); void log(String event); }

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

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

Вопрос 12 из 20

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

mixin Audited on Repository {
  void saveWithAudit(String value) {
    save(value);
    log('saved:$value');
  }
}
abstract class Repository { void save(String value); void log(String event); }

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

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

Вопрос 13 из 20

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

mixin Audited on Repository {
  void saveWithAudit(String value) {
    save(value);
    log('saved:$value');
  }
}
abstract class Repository { void save(String value); void log(String event); }

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

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

Вопрос 14 из 20

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

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

Вопрос 15 из 20

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

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

Вопрос 16 из 20

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

abstract interface class Clock { DateTime now(); }
class ExpiringToken {
  ExpiringToken(this.clock, this.expiresAt);
  final Clock clock;
  final DateTime expiresAt;
  bool get expired => !clock.now().isBefore(expiresAt);
}

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

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

Вопрос 17 из 20

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

abstract interface class Clock { DateTime now(); }
class ExpiringToken {
  ExpiringToken(this.clock, this.expiresAt);
  final Clock clock;
  final DateTime expiresAt;
  bool get expired => !clock.now().isBefore(expiresAt);
}

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

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

Вопрос 18 из 20

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

abstract interface class Clock { DateTime now(); }
class ExpiringToken {
  ExpiringToken(this.clock, this.expiresAt);
  final Clock clock;
  final DateTime expiresAt;
  bool get expired => !clock.now().isBefore(expiresAt);
}

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

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

Вопрос 19 из 20

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

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

Вопрос 20 из 20

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

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