Каковы реальные плюсы и минусы каждой из основных насмешек?

Question

см. Также " Что следует учитывать, когда выбирая насмешливые рамки для .Net"

Я пытаюсь выбрать модель для использования в .NET-проекте, который я недавно начал. Я хотел бы ускорить мои исследования в различных рамках. Я недавно прочитал эту запись в блоге http://codevanced.net/post/Mocking-frameworks-comparison.aspx и подумал, есть ли у какой-либо из аудитории StackOverflow что-нибудь, что можно добавить к реальным преимуществам и предостережениям в рамках.

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

• RhinoMocks
• Moq
• TypeMock Isolator
• NMock
• Родинки

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

Answer 1

Я вообще не знаю кротов, но я расскажу о тех, о которых знаю немного (хотя мне действительно нужен стол для этого).

Moq

Плюсы

• Типобезопасный
• Согласованный интерфейс
• Поощряет хороший дизайн

Против

• Не так полнофункциональный, как некоторые из его конкурентов
  • Это не может издеваться над делегатами
  • Это не может сделать упорядоченные ожидания
  • вероятно, другие вещи, о которых я не могу думать сейчас ...
• Может только макетировать интерфейсы и виртуальные / абстрактные элементы

Rhino Mocks

Плюсы

• Типобезопасный
• Полный набор функций
• Поощряет хороший дизайн

Против

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

TypeMock Isolator

Плюсы

• Тип безопасности (AFAIR)
• Может издеваться все, что угодно

Против

• Очень инвазивный
• Потенциальная блокировка поставщика
• Не поощряет хороший дизайн

NMock

Плюсы

• Поощряет хороший дизайн
• Работает на любой версии .NET (даже 1.1)

Против

• Не типобезопасно
• Может только макетировать интерфейсы и виртуальные / абстрактные элементы

Обращаем ваше внимание, что преимущества и недостатки TypeMock особенно противоречивы. Я опубликовал мое собственное мнение по этому вопросу в своем блоге .

Я начал с NMock, когда это было единственной возможностью еще в 2003 году, затем перешел на Rhino Mocks из-за его безопасности типов и теперь использую Moq из-за более простого API.

Answer 2

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

Answer 3

Как Фрэнк и Крис, я попробовал RhinoMocks и переключился на Moq. Я не был разочарован. Смотрите мою серию постов в блоге:

• Проблемы с заглушкой с помощью Rhino Mocks
• Издевается: следующее поколение
• Издевается: следующее поколение II
• Переключение на Moq

РЕДАКТИРОВАТЬ: Обратите внимание, что я обычно делаю тестирование на основе состояния с заглушками; Я редко провожу тестирование поведения с помощью проверяемых макетов.

Answer 4

Мы использовали Rhino Mocks уже больше года. PRO:

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

ПРОТИВ:

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

Как общее примечание, мы обнаружили, что использование фальшивых фреймворков способствует тестированию "белого ящика" (особенно для юнит-тестов). Мы закончили тестами, которые подтвердили, КАК все было сделано, а не ЧТО они делали. Они были бесполезны для рефакторинга, и нам пришлось переписать большинство из них.

Answer 5

Я использую TypeMock, так как я занимаюсь разработкой на SharePoint. Поскольку TypeMock может что-то издеваться, он оказался ценным ресурсом при модульном тестировании наших веб-частей SharePoint, приемников событий, рабочих процессов и т. Д.

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

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

Answer 6

Я не использовал все эти фреймворки, но я посмотрел на RhinoMocks и Moq, и пошел с Moq, потому что он выглядит более элегантным и намного проще. Я использую транковую версию, которая включает обязательное исправление для ограничения в 4 аргумента, наложенного на обратные вызовы в самой последней бета-версии 4.0.

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

Answer 7

Возможно, вы захотите иметь в виду, что если вам потребуется поддержка многоязычной среды (например, VB), все конфигурируемые с помощью кода структуры (я могу напрямую поговорить с Moq и RhinoMocks) будут болезненными, учитывая (отсутствие из) анонимный делегат / лямбда-синтаксис в VB. Это будет более возможно в Visual Studio 2010 / VB 10, но все равно не будет сопоставимо с хорошим лямбда-синтаксисом C #.

Похоже, что TypeMock имеет некоторую поддержку VB