Что такое макет и когда вы должны его использовать?

Question

Я только что прочитал статью в Википедии о фиктивных объектах , но я до сих пор не до конца понимаю их назначение. Похоже, что они являются объектами, которые создаются тестовой средой, когда фактический объект будет слишком сложным или непредсказуемым (вы на 100% уверены, каковы значения фиктивного объекта, поскольку вы полностью управляете ими).

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

Answer 1

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

Существуют фиктивные структуры, которые позволяют вам создавать эти объекты на лету и, по сути, позволяют вам сказать что-то вроде: Сделайте мне объект с методом foo, который принимает int и возвращает bool. Когда я передаю 0, оно должно возвращать true. Затем вы можете проверить код, который использует foo (), чтобы убедиться, что он реагирует соответствующим образом.

У Мартина Фаулера есть отличная статья о насмешках:

• http://martinfowler.com/articles/mocksArentStubs.html

Answer 2

Подумайте о классическом случае использования клиентского и серверного программного обеспечения. Чтобы протестировать клиент, вам нужен сервер; чтобы проверить сервер, вам нужен клиент. Это делает модульное тестирование практически невозможным - без использования макетов. Если вы издеваетесь над сервером, вы можете протестировать клиента изолированно и наоборот.

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

Answer 3

Я согласен со всем @ Лу Франко говорит, и вы обязательно должны прочитать превосходную статью Мартина Фаулера о двойных тестах, на которую @Lou Franco указывает вам.

Основная цель любого двойного теста (подделка, заглушка или макет) состоит в том, чтобы изолировать тестируемый объект, чтобы ваш модульный тест проверял только этот объект (не его зависимости и другие типы, с которыми он взаимодействует или взаимодействует). 1005 *

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

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

Answer 4

Вот пример: если вы пишете код, который заполняет базу данных, вы можете проверить, добавил ли конкретный метод данные в базу данных.

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

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

Макет позволяет вам держать тесты независимыми друг от друга и легко настраивать.

Это только один пример - я уверен, что другие могут предоставить больше.

Я согласен на 100% с другими участниками этой темы, особенно с рекомендацией к статье Мартина Фаулера.

Answer 5

Вас может заинтересовать наша книга, см. http://www.growing -object-oriented-software.com / . Это на Java, но идеи все еще применимы.