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

Question

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

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

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

Answer 5

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