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

Question

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

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

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

Спасибо

Answer 1

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

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

" Я не нахожу веских причин для переключаясь на Mocking Frameworks от рукописные заглушки . "

Я был точно таким же. Почему я должен заниматься изучением насмешливых рамок? Рукописные заглушки хорошо.

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

Преимущества насмешливой основы:

• Проще ( субъективно, но через некоторое время вы не будете писать рукописные реализации )
• Less Code ( фреймворки позволяют создавать макет за несколько строк, а не за полные объявления классов )
• следует за СУХОЙ ( вы не станете повторять ложные реализации )

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

Answer 2

Возможно, вы захотите прочитать статью Мартина Фаулера Насмешки - не заглушки . Основное отличие заключается в следующем:

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

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

Answer 5

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