Каковы реальные за и против каждой из главных платформ насмешки?
При отладке я нахожу представление "Display" действительно полезным. Это позволяет Вам ввести код (использующий автоматический завершенный) и позволяет Вам выполнить/отобразить результат того, что Вы пишете.
Дают ему попытку!
7 ответов
Если вы все же решили пойти по пути демона, есть отличный модуль PEAR под названием System_Daemon , который я недавно успешно использовал при установке PHP v5.3.0. Он задокументирован в блоге авторов: http://kevin.vanzonneveld.net/techblog/article/create_daemons_in_php
Если у вас установлен PEAR, вы можете установить этот модуль, используя:
pear install -f System_Daemon
Вам также потребуется создайте скрипт инициализации: /etc/init.d/
Затем вы можете:
- Запустить демон:
/etc/init.d/projNotifMailDaemon start - Остановить демон:
- Он не может имитировать делегатов
- Он не может выполнять упорядоченные ожидания
- , возможно, другие вещи, о которых я не могу сейчас думать ...
- Может только имитировать интерфейсы и виртуальные / абстрактные члены
] Rhino Mocks
Плюсы
- Типобезопасность
- Полный набор функций
- Поощряет хороший дизайн
Минусы
- Запутывает API. Существует слишком много разных способов делать одни и те же вещи, и если вы объедините их неправильно, это просто не сработает.
- Может имитировать только интерфейсы и виртуальные / абстрактные элементы
TypeMock Isolator
Плюсы
- Типобезопасность (AFAIR)
- Может имитировать что угодно
Минусы
- Очень инвазивно
- Потенциальная привязка к поставщику
- Не способствует хорошему дизайну
NMock
Плюсы
- Поощряет хороший дизайн
- Работает на любой версии .NET (даже 1. 1)
Минусы
- Не типобезопасен
- Может имитировать только интерфейсы и виртуальные / абстрактные члены
Обратите внимание, что особенно преимущества и недостатки TypeMock весьма спорны. Я опубликовал свой собственный взгляд на этот вопрос в моем блоге .
Я начал с NMock, когда это был единственный вариант еще в 2003 году, затем перешел на Rhino Mocks из-за его безопасности типов, и теперь использую Moq из-за более простого API.
До сих пор я использовал RhinoMocks и Moq. Moq в настоящее время является моим фаворитом из-за его простоты, которая в настоящее время является всем, что мне нужно. RhinoMocks - довольно мощный инструмент, но я никогда не был в состоянии полностью задействовать его.
Мы используем Rhino Mocks уже больше года. тестирование (особенно для модульных тестов). В итоге мы получили тесты, которые проверяли, КАК все было сделано, а не ЧТО они делали. Они были бесполезны для рефакторинга, и нам пришлось переписать большинство из них.
Как и Фрэнк и Крис, я попробовал RhinoMocks и переключился на Moq. Я не был разочарован. См. Мою серию сообщений в блоге:
- Проблемы с заглушками в Rhino Mocks
- Mocks: The Next Generation
- Mocks: The Next Generation II
- Switching to Moq
EDIT: Обратите внимание, что я обычно утверждаю - тестирование на основе заглушек; Я редко провожу тестирование поведения с проверяемыми имитами.
Я не использовал все эти фреймворки, но я посмотрел на RhinoMocks и Moq и выбрал Moq, потому что он кажется более элегантным и намного более простым. Я использую магистральную версию, которая включает обязательное исправление для ограничения 4 аргументов, наложенного на обратные вызовы в последней бета-версии 4.0.
Мне особенно нравится поведение Moq по умолчанию, которое не ведет себя как строгий Mock Object неудачные тесты при неожиданных звонках. Вы можете настроить его для этого, если хотите, но я считаю, что это требует от меня слишком много времени на настройку ожиданий и мало времени на тестирование.
Вы можете иметь в виду, что если вам нужно поддерживать многоязычную среду (например, VB) все настраиваемые фреймворки кода (я могу говорить напрямую с Moq и RhinoMocks) будут болезненными, учитывая (отсутствие) синтаксиса анонимного делегата / лямбда в VB. Это будет более возможно в Visual Studio 2010 / VB 10, но все равно не будет сопоставимо с красивым лямбда-синтаксисом C #.
Я использую TypeMock, так как разрабатываю на SharePoint. Поскольку TypeMock может имитировать что угодно, он оказался ценным ресурсом при модульном тестировании наших веб-частей SharePoint, приемников событий, рабочих процессов и т. Д.
С другой стороны, TypeMock может быть дорогостоящим, однако доступна версия , которая специфичен для SharePoint и стоит меньше, чем полный пакет TypeMock. Я настоятельно рекомендую его.
Единственное, с чем я не согласен, - это мнение о том, что TypeMock не способствует хорошему проектированию кода. Часто классы, которые я создаю, и весь код разрабатываются хорошо. То, что я использую TypeMock, не означает, что я жертвую качеством своего дизайна - я все еще практикую IoC и SRP. Тот факт, что TypeMock может имитировать что угодно, не означает, что я пишу код, отражающий эту способность.