Блог

Поскольку я использую RhinoMocks версии 3.6 и поскольку я не использую Record-Replay и поскольку я не вызываю методы проверки для утверждения в mocks;

Можете ли вы объяснить, в чем разница между очень просто?

 MockRepository.GenerateMock()
MockRepository.GeneratePartialMock()
MockRepository.GenerateStrictMock()
  

Примечание: я использую .Постоянно генерируйте MOCK для создания моих макетов, и я утверждаю вызовы методов, уже предоставляя ожидаемые аргументы.

Различия объясняются в этой статье

Если вы не создаете никаких ожиданий для a StrictMock , и метод вызывается в макете, будет выдано исключение.

Если вы не создаете никаких ожиданий для a PartialMock , и метод вызывается в макете, ничего особенного не происходит. Если этот макет является производным от базового класса, вызов переходит к существующей базовой реализации.

Существует также нечто, называемое a DynamicMock . Если вы не создаете никаких ожиданий для a DynamicMock , и в макете вызывается метод, вызывается метод-заглушка. Если было возвращаемое значение, возвращается значение по умолчанию (например null , или 0 ).

GenerateMock Я считаю, что создает DynamicMock .

Айенде выбрал это значение по умолчанию, потому что он рекомендует в идеале использовать только DynamicMock and Stub . StrictMock создает хрупкие тесты и обычно нарушает концепцию проверки только одного поведения для каждого теста.

Смотрите эту статью: http://ayende.com/wiki/Rhino Mocks 3.5.ashx#CreateMockisdeprecated,replacedbyStrictMockTheuseofStrictMockisdiscouraged

Я также видел, как он говорил, что полезно начинать со строгих макетов и возвращать свои тесты к динамическим макетам / заглушкам, как только вы будете довольны тем, как ведет себя ваш тестируемый код. Для этого нет ссылки 🙂

Я должен добавить, что «использование Strict Mock не рекомендуется» словами Айенде. http://ayende.com/wiki/Rhino Mocks 3.5.ashx#CreateMockisdeprecated,replacedbyStrictMockTheuseofStrictMockisdiscouraged

Он говорит:

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

Я рекомендую вместо этого использовать заглушки и динамические макеты.