Каковы ключевые факторы при выборе Mocking Framework?

Я ищу, чтобы начать с объектами в моих модульных тестах. Кажется, есть множество хороших насмешливых рамок.

1. У разных фреймворков разная целевая аудитория?
2. Какие факторы я должен учитывать при выборе подходящей структуры для моей ситуации?

У разных фреймворков разная целевая аудитория?

Да. Некоторые фреймворки, такие как Microsoft Moles , TypeMock Isolator и JustMock , позволяют вам высмеивать что угодно. Эти инструменты для подражания, как правило, лучше для разработчиков, желающих использовать их в существующем унаследованном коде, поскольку может оказаться невозможным преобразовать их в более удобный для тестирования дизайн. *

Традиционно тестируемые проекты означают, что кодовая база должна свободно использовать интерфейсы, абстрактные классы, виртуальные методы, незапечатанные классы и т. Д. Следовательно, традиционные среды для моделирования, такие как Moq и RhinoMocks, хорошо работают с кодом, разработанным с использованием Test Driven Development, Dependency Injection и другие такие понятия. Кстати, я очень рекомендую использовать Dependency Injection, поскольку вы получаете гораздо больше, чем просто тестируемый код, но также и более поддерживаемый код.

Какие факторы я должен учитывать при выборе подходящей структуры для моей ситуации?

• Деятельность по развитию. Такие инструменты, как Moq и RhinoMocks, очень активны и популярны и, следовательно, актуальны.
• Open Source Vs. коммерческий . Рассмотрим различные плюсы и минусы, характерные для этого сравнения. Стоимость, поддержка и т.д ...
• Зрелость. Насколько новый инструмент. Это бета-версия (например, Microsoft Moles) или несколько стабильных выпусков? Например, мне нравится Moles для унаследованного кода, но в нем есть несколько ошибок, которые необходимо устранить, и мы будем ждать, пока они не будут устранены (следующий выпуск, ноябрь 2011 г.).
• Документация. Существует несколько книг и блогов, посвященных модульному тестированию, макетированию, автомоделированию и т. Д. Кроме того, насколько хороша собственная документация инструмента?
• Синтаксис . У каждого инструмента есть свой способ сказать то же самое. Посмотрите, какой из них лучше подходит для вас.
• Скорость . Инструменты, использующие CLR-профилирование (TypeMock, Moles, JustMock), могут работать намного медленнее, чем традиционные (Moq, RhinoMocks). Это снижение скорости может быть проблемой, так как вы набираете много юнит-тестов. Эмпирическое правило: если тест занимает больше 1/10 секунды, он слишком медленный.
• Поддержка сообщества . Другие разработчики пишут другие инструменты, которые расширяют (или работают в комплимент) инструмент для насмешек? Существует проект Moq.Contrib, который добавляет в Moq возможность Auto- mocking (которая помогает сократить время написания теста). А еще лучше, есть AutoFixture , AutoFixture.AutoMoq, AutoFixture.AutoRhinoMocks, который также позволяет Auto-mocking, плюс создание анонимных переменных.

^{* См. Эффективная работа с унаследованным кодом , чтобы узнать, как медленный рефакторинг кода без тестов в код, который можно использовать с традиционными инструментами тестирования (и насмешек).}

Учебник Moq имеет раздел на фоне, философии и споры в самом начале , где обсуждается это в отношении нескольких конкретных инструментов: TypeMock изолятор, RhinoMocks и Moq. Он написан для объяснения Moq, поэтому, естественно, немного искажен, но я обнаружил, что это очень полезно для меня, когда я пытаюсь понять некоторые различия в фреймворках.

Я нашел ответы на эту тему SO на C # Mocking Frameworks также полезными. Большинство просто ссылаются на одну Mocking Framework, которую пользователь действительно считает полезной, но есть ответ от HaraldV о путях, которые обсуждают прокаты на основе прокси и профилирования на основе профилировщика.

Я также смог найти таблицу сравнения в Интернете. Обратите внимание, что это с 2009 года, поэтому я не уверен, что это актуально; есть по крайней мере один комментарий, в котором говорится, что информация о TypeMock и обратных вызовах устарела, но диаграмма может быть полезна для постановки вопросов, которые следует учитывать, даже если вам нужно будет выполнить работу, чтобы увидеть текущее состояние: RhinoMocks, Moq, NMock, и сравнительная таблица TypeMock

В Google Code есть проект с тестовыми примерами в нескольких средах моделирования для простого сравнения кода: mocking-frameworks-Compare

1. Простота использования. Некоторые из структур имеют более продвинутые идиомы использования. Например, MOQ позволяет использовать лямбды для кодирования ожиданий. Некоторые старые библиотеки не поддерживают это.
2. Скорость. Каждый модульный тест должен быть быстрым, чтобы вся ваша библиотека не работала часами. Некоторые фальшивые фреймворки имеют статически сгенерированные макеты, что быстро. Другие платформы динамически генерируют код во время выполнения, что медленнее.
3. Служба поддержки. Вам нужна среда, которая активно поддерживается с исправлениями и обновляется для поддержки новых версий .NET по мере их выпуска.
4. Мощность. Большинство исследованных мной насмешливых рамок примерно одинаковы по мощности. Есть одно заметное исключение. Microsoft Moles позволяет высмеивать «не виртуальные / статические методы в закрытых типах». Насколько мне известно, это то, что не поддерживает никакая другая насмешливая структура.

В моей команде мы выбрали Microsoft Moles . Он значительно выигрывает на # 2, # 3 и # 4, хотя он менее идиоматичен, чем большинство альтернатив, и находится на низком уровне на # 1.