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

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

мы уже больше года используем насмешки носорогов. PRO:

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

против:

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

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

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

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

EDIT: обратите внимание, что я обычно делаю тестирование на основе состояний с заглушками; я редко делаю тестирование поведения с проверяемыми насмешками.

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

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

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

с другой стороны, TypeMock может быть дорогим, однако есть версия доступно, что специфично для SharePoint и стоит меньше, чем полный пакет TypeMock. Очень рекомендую.

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

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

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