Нужны ли нам рамки изоляции для создания заглушек?

Question

Я прочитал это: http://martinfowler.com/articles/mocksArentStubs.html Мои представления о заглушке и издевательстве ясны.Я понимаю необходимость в изолированных средах, таких как moq, rhinomocks и т.п., чтобы создать фиктивный объект.Как замечательно, участвуйте в реальных проверках ожиданий.Но зачем нам эти рамки для создания заглушек.Я бы предпочел выкатить заглушку, созданную вручную, и использовать ее в различных приспособлениях.

Answer 1

Вы пытались использовать библиотеку, такую ​​как Rhino Mocks, в течение дня или двух, прежде чем решили, что свернутые вручную заглушки - лучший вариант?

@ chibacity: вся идея насмешливых библиотек состоит в том, чтобы избегать реализаций. Если мне нужно только установить значение одного свойства, я не хочу создавать полную реализацию интерфейса. Телефонный код типа

MyObj obj = MockRepository.GenerateStub<MyObj>();
obj.MyProperty = 33;

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

Это не означает, что вы не должны выкатывать свои собственные заглушки для более сложных сценариев, но по моему опыту такие случаи редки.

Моя рекомендация - научиться использовать хорошую библиотеку для насмешек (например, Rhino) со всеми ее маленькими хитростями, и я уверен, что вы скоро научитесь понимать причины ее существования.

Answer 2

Строго говоря, нет, не требуется изоляционная структура для создания заглушек.На самом деле, у Microsoft даже есть Stubs Framework , который only генерирует заглушки, а не издевательства.

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

Что касается вашего последнего предложения («Я бы предпочел выкатить заглушку, созданную вручную, и использовать ее в различных приспособлениях»),Вы на самом деле пробовали это на любом значительном проекте?Конечно, может быть, у вас есть интерфейс с единственным методом, который возвращает обнуляемое значение bool - вам нужно написать только три заглушки для этого интерфейса, и это не так уж и плохо.

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

Answer 3

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

Тогда для меня становится проблемой создание слоев абстракции. Я должен подвергнуть сомнению, где что-то должно взаимодействовать на определенных уровнях. Это помогает в создании этого «Последнего ответственного момента». Так что я получаю объекты, у которых есть производители и потребители. И все, что между ними - просто каналы сообщений.

Надеюсь, это поможет.