модульное тестирование EJB 3.1 - зачем макетировать контейнерные сервисы

Question

В чем преимущество насмешки над контейнерными сервисами в модульном тестировании EJB 3.1?

Возможные ответы, которые я получаю, когда я думаю об этом,

1. Улучшает производительность тестов.
2. Он не подчиняется правилам модульного тестирования, поскольку существует множество взаимодействий с другими API. (Пожалуйста, выскажите свое мнение по этому поводу)

Кроме этих, как вы думаете, есть и другие преимущества?

Как многие из вас могут знать, можно протестировать некоторые из услуг, предоставляемых контейнером, такие как постоянство, управление транзакциями (например, с помощью Bitronix), обмен сообщениями (например, с использованием Apache ActiveMQ и JNDI в памяти) контейнера в вашей собственной JVM. Тем не менее, есть аргумент, что это интеграционное тестирование, и юнит-тестирование не должно проводиться таким образом.

По моему мнению, если у вас может быть хорошая производительность в ваших тестах, то неплохо использовать эти сторонние реализации для модульного тестирования, потому что вам не нужно тратить слишком много времени на макетирование, а симуляция сильно подвержена ошибкам разработчика , Если у разработчика нет хорошего понимания насмешек, он может в конечном итоге высмеивать все или, другими словами, неправильно использовать издевательства, чтобы сделать тесты «зелеными». Это правильно? (Пожалуйста, выскажите свое мнение по этому поводу)

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

Спасибо.

Answer 1

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

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

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

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

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

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

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