Подтвердить что ты не робот

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

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

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

4b9b3361

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

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

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