Классы и конструкторы — бесплатный тест онлайн

Вопрос 1 из 20

Локальная заплатка помогла только одному клиенту этого кода. Какая правка устраняет причину в теме «Инициализаторы»?

class Range {
  Range(this.start, this.end) : assert(start <= end);
  final int start;
  final int end;
  int get length => end - start;
}
void main() => print(Range(2, 7).length);

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

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

Вопрос 2 из 20

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

class Range {
  Range(this.start, this.end) : assert(start <= end);
  final int start;
  final int end;
  int get length => end - start;
}
void main() => print(Range(2, 7).length);

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

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

Вопрос 3 из 20

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

class Range {
  Range(this.start, this.end) : assert(start <= end);
  final int start;
  final int end;
  int get length => end - start;
}
void main() => print(Range(2, 7).length);

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

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

Вопрос 4 из 20

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

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

Вопрос 5 из 20

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

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

Вопрос 6 из 20

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

class Point {
  const Point(this.x, this.y);
  const Point.origin() : this(0, 0);
  final int x; final int y;
}
void main() => print(const Point.origin().x);

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

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

Вопрос 7 из 20

Локальная заплатка помогла только одному клиенту этого кода. Какая правка устраняет причину в теме «Именованные конструкторы»?

class Point {
  const Point(this.x, this.y);
  const Point.origin() : this(0, 0);
  final int x; final int y;
}
void main() => print(const Point.origin().x);

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

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

Вопрос 8 из 20

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

class Point {
  const Point(this.x, this.y);
  const Point.origin() : this(0, 0);
  final int x; final int y;
}
void main() => print(const Point.origin().x);

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

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

Вопрос 9 из 20

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

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

Вопрос 10 из 20

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

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

Вопрос 11 из 20

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

class User {
  User._(this.id);
  static final _cache = <int, User>{};
  factory User(int id) => _cache.putIfAbsent(id, () => User._(id));
  final int id;
}
void main() => print(identical(User(1), User(1)));

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

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

Вопрос 12 из 20

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

class User {
  User._(this.id);
  static final _cache = <int, User>{};
  factory User(int id) => _cache.putIfAbsent(id, () => User._(id));
  final int id;
}
void main() => print(identical(User(1), User(1)));

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

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

Вопрос 13 из 20

Локальная заплатка помогла только одному клиенту этого кода. Какая правка устраняет причину в теме «Фабрики»?

class User {
  User._(this.id);
  static final _cache = <int, User>{};
  factory User(int id) => _cache.putIfAbsent(id, () => User._(id));
  final int id;
}
void main() => print(identical(User(1), User(1)));

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

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

Вопрос 14 из 20

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

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

Вопрос 15 из 20

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

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

Вопрос 16 из 20

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

class Account {
  Account(int cents) : _cents = cents {
    if (cents < 0) throw ArgumentError.value(cents);
  }
  int _cents;
  int get cents => _cents;
  void debit(int value) {
    if (value < 0 || value > _cents) throw StateError('balance');
    _cents -= value;
  }
}

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

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

Вопрос 17 из 20

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

class Account {
  Account(int cents) : _cents = cents {
    if (cents < 0) throw ArgumentError.value(cents);
  }
  int _cents;
  int get cents => _cents;
  void debit(int value) {
    if (value < 0 || value > _cents) throw StateError('balance');
    _cents -= value;
  }
}

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

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

Вопрос 18 из 20

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

class Account {
  Account(int cents) : _cents = cents {
    if (cents < 0) throw ArgumentError.value(cents);
  }
  int _cents;
  int get cents => _cents;
  void debit(int value) {
    if (value < 0 || value > _cents) throw StateError('balance');
    _cents -= value;
  }
}

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

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

Вопрос 19 из 20

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

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

Вопрос 20 из 20

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

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