Почему нам нужны платформы насмешки как Easymock, JMock или Mockito?

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

Простой ответ: мы не в них нуждаемся.

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

« Я не нахожу веской причины для перехода на фреймворки Mocking с рукописных заглушек .»

Я был точно таким же. Зачем мне вообще учить фреймворк? Написанные от руки окурки подойдут.

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

Преимущества макета фреймворка:

• Легче ( субъективно, но через некоторое время вы не будете писать рукописные реализации )
• Меньше кода ( фреймворки позволяют создавать макет в нескольких строках, а не полное объявление класса )
• Следует за DRY ( вы не будете в конечном итоге повторять реализации макета )

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

Вы можете прочитать статью Мартина Фаулера Mocks Aren't Stubs . Основное различие заключается в следующем:

• Задача заглушки - возвращать известные результаты для всех вызовов.
• Мок дополнительно ожидает, что вызовы будут поступать в определенном порядке с определенными параметрами, и вызовет исключение, когда эти ожидания не будут выполнены. .

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

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

Я начинал так же (писал макеты вручную) и к настоящему времени почти полностью перешел на EasyMock.

Я обнаружил, что использование EasyMock обычно и быстрее, и гибче.

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

Прекрасно, скажете вы, это только одноразовые затраты. В следующий раз я смогу просто повторно использовать написанный вручную макет... Я обнаружил, что часто это не так. В другом тесте мне может понадобиться макет того же класса с другим поведением. Например, вызываются разные методы, и/или ожидается другой результат. Особый случай - это когда макет должен выбросить исключение в одном тестовом случае, но не в другом. Хорошо, я могу добавить к нему некоторые параметры, которые управляют поведением динамически. Затем для следующего теста - еще несколько параметров, которые будут контролировать еще большее поведение... в итоге я получаю все более сложную реализацию имитатора, которая является зависимостью для все большего количества модульных тестов, что также создает риск непреднамеренного нарушения старых тестов.

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

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

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

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

Другими словами, использование mocking framework - это то же самое, что и использование любой другой сторонней библиотеки, например, ORM - кто-то другой написал код, чтобы вам не пришлось этого делать.