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

Question

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

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

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

Примечание. Я все время использую .GenerateMock, чтобы создавать свои макеты, и я утверждаю вызовы методов, предоставляя уже ожидаемые аргументы.

Answer 1

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

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

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

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

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

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

См. Эту статью: http://ayende.com/wiki/Rhino%20Mocks%203.5.ashx#CreateMockisdeprecated,replacedbyStrictMockTheuseofStrictMockisdiscouraged

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

Answer 2

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

Он говорит:

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

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