Войти
В объектно-ориентированном программировании, фиктивные объекты - это смоделированные объекты, имитирующие поведение реальных объектов управляемыми способами, чаще всего в рамках инициативы тестирования программного обеспечения. Программист обычно создает фиктивный объект для проверки поведения какого-либо другого объекта, почти так же, как конструктор автомобилей использует манекен для краш-тестов для имитации динамического поведения человека. при ударах автомобиля. Этот метод также применим в универсальном программировании.
В модульном тесте, фиктивные объекты могут моделировать поведение сложных реальных объектов и поэтому полезны, когда реальный объект непрактичен или невозможно включить в модульный тест. Если объект имеет любую из следующих характеристик, может быть полезно использовать вместо него фиктивный объект:
Например, программа-будильник, которая заставляет звонок звонить в определенное время, может получить текущее время от службы времени. Чтобы проверить это, тест должен дождаться времени будильника, чтобы узнать, правильно ли он прозвенел. Если служба фиктивного времени используется вместо службы реального времени, ее можно запрограммировать на обеспечение времени звонка (или любого другого времени) независимо от реального времени, так что программа будильника может быть протестирована изолированно.
Мок-объекты имеют тот же интерфейс, что и реальные объекты, которые они имитируют, что позволяет клиентскому объекту не знать, использует ли он реальный объект или фиктивный объект. Многие доступные фреймворки фиктивных объектов позволяют программисту указать, какие и в каком порядке методы будут вызываться для фиктивного объекта и какие параметры будут переданы им, а также какие значения будут возвращены. Таким образом, поведение сложного объекта, такого как сетевой сокет, можно имитировать с помощью фиктивного объекта, что позволяет программисту определить, реагирует ли тестируемый объект надлежащим образом на большое разнообразие состояний, в которых могут находиться такие фиктивные объекты.
Классификация имитаторов, фейков и заглушек в литературе очень противоречива. Тем не менее, согласно литературным источникам, все они представляют собой производственный объект в среде тестирования, открывая один и тот же интерфейс.
Что из имитаций, подделок или заглушек является самым простым, непоследовательно, но самый простой всегда возвращает заранее подготовленные ответы (как в заглушке метода ). С другой стороны, наиболее сложный объект будет полностью имитировать производственный объект с полной логикой, исключениями и т. Д. Подходит ли какое-либо трио имитация, подделка или заглушка такому определению, опять же, противоречиво во всем литература.
Например, реализация имитационного, поддельного или заглушенного метода между двумя концами спектра сложности может содержать утверждения для проверки контекста каждого вызова. Например, фиктивный объект может утверждать порядок, в котором вызываются его методы, или утверждать согласованность данных между вызовами методов.
В книге Искусство модульного тестирования моки описываются как фальшивый объект, который помогает решить, не прошел ли тест, путем проверки того, произошло ли взаимодействие с объектом. Все остальное определяется как заглушка. В этой книге под фейками понимается все, что не является настоящим, что в зависимости от их использования может быть либо заглушкой, либо имитацией.
Рассмотрим пример, в котором подсистема авторизации была имитирована. Мок-объект реализует метод isUserAllowed (task: Task): boolean, чтобы соответствовать таковому в реальном классе авторизации. Если он также предоставляет свойство isAllowed: boolean, которого нет в реальном классе, это дает множество преимуществ. Это позволяет тестирующему коду легко установить ожидание того, что пользователю будет или не будет предоставлено разрешение при следующем вызове, и, следовательно, легко протестировать поведение остальной системы в любом случае.
Аналогичным образом, настройки «только имитация» могут гарантировать, что последующие вызовы подсистемы вызовут выдачу исключения, зависание без ответа или возврат ноль и т. Д. Таким образом, можно разработать и протестировать поведение клиента для реальных условий сбоя в внутренних подсистемах, а также для их ожидаемых ответов. Без такой простой и гибкой имитирующей системы тестирование каждой из этих ситуаций может оказаться слишком трудоемким для их рассмотрения.
Метод save (person: Person)фиктивного объекта базы данных может не содержать большого количества (если есть) кода реализации. Он может проверить наличие и, возможно, действительность объекта Person, переданного для сохранения (см. Обсуждение фальшивого и фиктивного выше), но кроме этого может не быть другой реализации.
Это упущенная возможность. Макетный метод может добавить запись в строку общедоступного журнала. Запись должна быть не более чем «Человек сохранен», или она может включать некоторые детали из экземпляра объекта человека, такие как имя или идентификатор. Если тестовый код также проверяет окончательное содержимое строки журнала после различных серий операций с фиктивной базой данных, то можно проверить, что в каждом случае было выполнено точно ожидаемое количество сохранений базы данных. Это может найти в противном случае невидимые ошибки, снижающие производительность, например, когда разработчик, опасаясь потери данных, закодировал повторные вызовы save (), где было бы достаточно всего одного.
Программисты, работающие с методом разработки через тестирование (TDD), используют фиктивные объекты при написании программного обеспечения. Мок-объекты отвечают требованиям interface более сложных реальных объектов и заменяют их; таким образом, они позволяют программистам писать и функциональные возможности модульного тестирования в одной области, не вызывая сложных базовых или взаимодействующих классов . Использование фиктивных объектов позволяет разработчикам сосредоточить свои тесты на поведении тестируемой системы, не беспокоясь о ее зависимостях. Например, тестирование сложного алгоритма, основанного на нескольких объектах, находящихся в определенных состояниях, может быть четко выражено с помощью фиктивных объектов вместо реальных.
Помимо проблем со сложностью и преимуществ, получаемых от разделения ответственности, существуют практические проблемы скорости. Разработка реалистичного программного обеспечения с использованием TDD может легко потребовать нескольких сотен модульных тестов. Если многие из них вызывают обмен данными с базами данных, веб-службами и другими внепроцессными или сетевыми системами, тогда набор модульных тестов быстро станет слишком медленным для регулярного выполнения. Это, в свою очередь, приводит к вредным привычкам и нежеланию разработчика поддерживать основные принципы TDD.
Когда фиктивные объекты заменяются реальными, сквозная функциональность потребует дальнейшего тестирования. Это будут интеграционные тесты, а не модульные тесты.
Использование фиктивных объектов может тесно связывать модульные тесты с реализацией тестируемого кода. Например, многие фреймворки имитирующих объектов позволяют разработчику проверять порядок и количество вызовов методов имитационных объектов реальным тестируемым объектом; последующий рефакторинг тестируемого кода может привести к сбою теста, даже если все методы имитируемых объектов по-прежнему подчиняются контракту предыдущей реализации. Это показывает, что модульные тесты должны тестировать внешнее поведение метода, а не его внутреннюю реализацию. Чрезмерное использование имитирующих объектов в составе набора модульных тестов может привести к резкому увеличению объема обслуживания, которое необходимо выполнять над самими тестами во время эволюции системы по мере проведения рефакторинга. Неправильное обслуживание таких тестов во время эволюции может позволить пропустить ошибки, которые в противном случае были бы обнаружены модульными тестами, использующими экземпляры реальных классов. И наоборот, простая имитация одного метода может потребовать гораздо меньше настроек, чем настройка всего реального класса, и, следовательно, снизить потребности в обслуживании.
Мок-объекты должны точно моделировать поведение имитируемого объекта, чего может быть трудно достичь, если фиктивный объект исходит от другого разработчика или проекта или если он еще даже не был написан. Если поведение не смоделировано правильно, то модульные тесты могут зарегистрировать прохождение, даже если сбой произойдет во время выполнения в тех же условиях, что и модульный тест, что делает модульный тест неточным.
