Когда целесообразно проводить тестирование на основе взаимодействия, а не тестирование на основе состояния?

Question

Когда я использую Easymock (или аналогичную среду для моделирования) для реализации своих модульных тестов, я вынужден проводить тестирование на основе взаимодействия (поскольку я не могу утверждать о состоянии моих зависимостей. ?).

С другой стороны, если я использую рукописную заглушку (вместо easymock), я могу реализовать тестирование на основе состояния.

Мне совершенно неясно, хочу ли я проводить тестирование на основе взаимодействия или тестирование на основе состояния.

Я пристрастен и хочу использовать Easymock, но я не уверен, будут ли какие-либо побочные эффекты, с которыми мне, возможно, придется столкнуться в будущем.

Кто-нибудь может пролить свет на это?

Заранее спасибо!

Answer 1

Вы должны разделить свои объекты на доменные объекты-значения (которые содержат состояние и должны быть неизменяемыми) и сервисы. Службы - это то, что другие объекты должны запрашивать для выполнения конкретной задачи, но ваш код не должен беспокоиться о том, как эта задача выполняется. Чтобы протестировать сервис изолированно, не тестируя его одноранговые узлы, используйте макет.

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

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

Answer 2

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

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

В этом случае могут помешать фальшивые фреймворки, а рукописная заглушка значительно упрощает управление состоянием для целей теста.

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

Answer 3

Я бы сказал, что концепция модульного тестирования переоценена. Мне очень нравится идея автоматического тестирования, но мне не нравится искусственное требование, чтобы вы тестировали только один модуль, а не систему / подсистему в целом.

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

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