Макет объекта

В информатике — макет объекта это объект , который ограниченным образом имитирует производственный объект. Программист обеспечения может использовать макет объекта в качестве тестового двойника для тестирования программного . Макет-объект также можно использовать в обобщенном программировании .

Аналогия

Макет объекта может быть полезен тестировщику программного обеспечения, как конструктор автомобилей использует манекен для краш-теста , чтобы имитировать человека при ударе транспортного средства.

Мотивация

В модульном тесте макеты объектов могут имитировать поведение сложных реальных объектов и поэтому полезны, когда реальный объект нецелесообразно или невозможно включить в модульный тест. Если объект имеет любую из следующих характеристик, может быть полезно использовать вместо него фиктивный объект:

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

Например, программа-будильник, которая заставляет звонок звонить в определенное время, может получить текущее время от службы времени. Чтобы проверить это, тест должен дождаться наступления будильника, чтобы узнать, правильно ли он прозвенел. Если вместо службы реального времени используется имитация службы времени, ее можно запрограммировать на предоставление времени звонка (или любого другого времени) независимо от реального времени, чтобы программу будильника можно было протестировать изолированно.

Технические детали

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

Моки, фейки и заглушки

Определения «mock», «fake » и «stub» в литературе не совпадают. ^[1]^[2]^[3]^[4]^[5]^[6] Тем не менее, все они представляют собой производственный объект в среде тестирования, предоставляя один и тот же интерфейс.

Независимо от имени, самая простая форма возвращает заранее подготовленные ответы (как в заглушке метода ), а самая сложная форма имитирует полную логику производственного объекта.

Такой тестовый объект может содержать утверждения для проверки контекста каждого вызова. Например, фиктивный объект может утверждать порядок вызова его методов или утверждать согласованность данных при вызовах методов.

В книге Искусство модульного тестирования. ^[7] макеты описываются как поддельный объект, который помогает решить, прошел ли тест или нет, проверяя, произошло ли взаимодействие с объектом. Все остальное определяется как заглушка. В этой книге подделками называют все, что не является реальным, что в зависимости от их использования может быть либо заглушкой , либо имитацией .

Установление ожиданий

Рассмотрим пример, где была осмеяна подсистема авторизации. Макетный объект реализует isUserAllowed(task : Task) : boolean^[8] метод, соответствующий этому в реальном классе авторизации. Если это также раскрывает isAllowed : boolean свойство, которого нет в реальном классе. Это позволяет тестовому коду легко установить ожидание того, что пользователю будет предоставлено или не будет разрешение при следующем вызове, и, следовательно, легко протестировать поведение остальной части системы в любом случае.

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

Запись строк журнала

Макет объекта базы данных save(person : Person) Метод может не содержать большого количества кода реализации (если таковой имеется). Он может проверить существование и, возможно, достоверность объекта Person, переданного для сохранения (см. обсуждение подделки и имитации выше), но кроме этого другой реализации может не быть.

Это упущенная возможность. Макетный метод может добавить запись в строку общедоступного журнала. Запись должна быть не более чем «Человек спасен». ^[9]^: 146–7 или он может включать некоторые сведения из экземпляра объекта person, например имя или идентификатор. Если тестовый код также проверяет окончательное содержимое строки журнала после различных серий операций с фиктивной базой данных, то можно убедиться, что в каждом случае было выполнено именно ожидаемое количество сохранений базы данных. Это позволяет обнаружить невидимые в противном случае ошибки, снижающие производительность, например, когда разработчик, опасаясь потери данных, закодировал повторяющиеся вызовы save() где достаточно было бы одного.

Использование в разработке через тестирование

Программисты, работающие с методом разработки через тестирование (TDD), используют макеты объектов при написании программного обеспечения. Мок-объекты соответствуют требованиям интерфейса и заменяют более сложные реальные объекты; таким образом, они позволяют программистам писать и выполнять модульное тестирование функций в одной области без вызова сложных базовых или взаимодействующих классов . ^[9]^: 144–5 Использование фиктивных объектов позволяет разработчикам сосредоточить свои тесты на поведении тестируемой системы, не беспокоясь о ее зависимостях. Например, тестирование сложного алгоритма, основанного на том, что несколько объектов находятся в определенных состояниях, можно четко выразить, используя фиктивные объекты вместо реальных объектов.

Помимо проблем сложности и преимуществ, получаемых от такого разделения задач , существуют практические проблемы скорости. Разработка реалистичного программного обеспечения с использованием TDD может легко включать несколько сотен модульных тестов. Если многие из них вызывают взаимодействие с базами данных, веб-сервисами и другими внепроцессными или сетевыми системами, то набор модульных тестов быстро станет слишком медленным для регулярного запуска. Это, в свою очередь, приводит к появлению вредных привычек и нежеланию разработчика соблюдать основные принципы TDD.

Когда фиктивные объекты заменяются реальными, сквозная функциональность потребует дальнейшего тестирования. Это будут интеграционные тесты, а не модульные тесты.

Ограничения

Использование макетов объектов может тесно связать модульные тесты с реализацией тестируемого кода. Например, многие платформы имитационных объектов позволяют разработчику проверять порядок и количество вызовов методов имитационных объектов реальным тестируемым объектом; последующий рефакторинг тестируемого кода может привести к сбою теста, даже если все методы имитируемого объекта по-прежнему подчиняются контракту предыдущей реализации. Это показывает, что модульные тесты должны проверять внешнее поведение метода, а не его внутреннюю реализацию. Чрезмерное использование макетов объектов в составе набора модульных тестов может привести к резкому увеличению объема обслуживания, которое необходимо выполнять для самих тестов во время эволюции системы по мере проведения рефакторинга. Неправильное сопровождение таких тестов во время эволюции может привести к тому, что будут пропущены ошибки, которые в противном случае были бы обнаружены модульными тестами, использующими экземпляры реальных классов. И наоборот, простая имитация одного метода может потребовать гораздо меньше настройки, чем настройка всего реального класса, и, следовательно, сократить потребности в обслуживании.

Мок-объекты должны точно моделировать поведение объекта, над которым они издеваются, чего может быть трудно достичь, если имитируемый объект создан другим разработчиком или проектом или еще даже не написан. Если поведение смоделировано неправильно, то модульные тесты могут зарегистрировать прохождение, даже если сбой может произойти во время выполнения в тех же условиях, в которых выполняется модульный тест, что делает модульный тест неточным. ^[10]

См. также

Ссылки

^ «Лучшие практики модульного тестирования с использованием .NET Core и .NET Standard — давайте говорить на одном языке (Fake, Stubs и Mocks)» . Документы Майкрософт . Архивировано из оригинала 3 сентября 2022 года.
^ Д'Арси, Гамлет (21 октября 2007 г.). «Моки и заглушки — не шпионы» . отстает от времени . Архивировано из оригинала 20 июня 2017 года.
^ «Издевательства, фейки, заглушки и пустышки» . XUnitPatterns.com . Архивировано из оригинала 17 января 2024 года.
^ «В чем разница между макетом и заглушкой?» . Переполнение стека . Архивировано из оригинала 4 июля 2022 года.
^ «В чем разница между фальсификацией, издевательством и заглушкой?» .
^ Перья, Майкл (2005). «Ощущение и разделение». Эффективная работа с устаревшим кодом . Нью-Джерси: Прентис Холл. п. 23 и далее. ISBN 0-13-117705-2 .
^ Ошеров, Рой (2009). «Тестирование взаимодействия с фиктивными объектами и др.». Искусство модульного тестирования . Мэннинг. ISBN 978-1-933988-27-6 .
^ В этих примерах используется номенклатура, аналогичная той, которая используется в Unified Modeling Language.
^ Перейти обратно: ^а ^б Бек, Кент (2003). Разработка через тестирование на примере . Бостон: Эддисон Уэсли. ISBN 0-321-14653-0 .
^ InJava.com — насмешка | О'Рейли Медиа

Внешние ссылки

Тим Маккиннон (8 сентября 2009 г.). «Краткая история макетов объектов» . Mockobjects.com/. Архивировано из оригинала 7 июня 2023 года.
Test Doubles : раздел книги, посвященный шаблонам модульного тестирования.
Все о макетах объектов! Портал о макетах объектов
«Использование макетов объектов для сложных модульных тестов» . IBM DeveloperWorks. 16 октября 2006 г. Архивировано из оригинала 4 мая 2007 г.
Модульное тестирование с использованием макетов объектов IBM DeveloperWorks
Mocks Are not Stubs ( Мартин Фаулер ) Статья о разработке тестов с использованием Mock-объектов. Определяет и сравнивает «классическую» и «издевательскую» школы тестирования. Затрагиваются моменты, влияющие на проектирование и обслуживание.

[1] «Лучшие практики модульного тестирования с использованием .NET Core и .NET Standard — давайте говорить на одном языке (Fake, Stubs и Mocks)» . Документы Майкрософт . Архивировано из оригинала 3 сентября 2022 года.

[2] Д'Арси, Гамлет (21 октября 2007 г.). «Моки и заглушки — не шпионы» . отстает от времени . Архивировано из оригинала 20 июня 2017 года.

[3] «Издевательства, фейки, заглушки и пустышки» . XUnitPatterns.com . Архивировано из оригинала 17 января 2024 года.

[4] «В чем разница между макетом и заглушкой?» . Переполнение стека . Архивировано из оригинала 4 июля 2022 года.

[5] «В чем разница между фальсификацией, издевательством и заглушкой?» .

[6] Перья, Майкл (2005). «Ощущение и разделение». Эффективная работа с устаревшим кодом . Нью-Джерси: Прентис Холл. п. 23 и далее. ISBN 0-13-117705-2 .

[7] Ошеров, Рой (2009). «Тестирование взаимодействия с фиктивными объектами и др.». Искусство модульного тестирования . Мэннинг. ISBN 978-1-933988-27-6 .

[8] В этих примерах используется номенклатура, аналогичная той, которая используется в Unified Modeling Language.

[Beck03-9] Перейти обратно: ^а ^б Бек, Кент (2003). Разработка через тестирование на примере . Бостон: Эддисон Уэсли. ISBN 0-321-14653-0 .

[10] InJava.com — насмешка | О'Рейли Медиа

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]