Пересмешка с использованием «традиционной» модели Record / Replay vs Moq

Question

Я новичок в мошенничестве и выбираю фальшивые рамки. Moq home цитаты

В настоящее время это единственный насмешливый библиотека, которая идет вразрез с обобщенный и несколько не интуитивный (особенно для новичков) Запись / Ответ подход из всех других структур.

Может кто-нибудь объяснить просто, что такое подход Record / Replay и чем отличается Moq? Каковы плюсы и минусы каждого, особенно с точки зрения определения основы?

Спасибо.

Answer 1

Подход Record / Replay поддерживается RhinoMocks . Основная идея заключается в том, что выполнение вашего теста разделено на две фазы: фазу записи и фазу воспроизведения. Чтобы быть немного более конкретным

var repo = new MockRepository();
var dependency = repo.DynamicMock<IDependency>();
With.Mocks(repo).Expecting(delegate {
         Expect.Call(dependency.AMethod(1)).Return(result);                    
      }).Verify(delegate {
         var sut = new Sut(wrappee);
         sut.DoStuffThatCallsAMethod();
         Assert.IsTrue(sut.ResultState);
      });

Таким образом, блок Expecting - это фаза записи, а блок Verify - фаза воспроизведения.

Moq-вариант этого кода будет

var dependency = new Mock<IDependency>();
dependency.Expect(dep => dep.AMethod(1)).Returns(result);          
var sut = new Sut(wrappee.Object);
sut.DoStuffThatCallsAMethod();
Assert.IsTrue(sut.ResultState);

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

Answer 2

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

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

У Moq есть возможность изменить значение, но оно несколько неуклюже (из документации)

// returning different values on each invocation 
var mock = new Mock<IFoo>(); 
var calls = 0; 
mock.Setup(foo => foo.GetCountThing())
.Returns(() => calls)
.Callback(() => calls++); 

Answer 3

Я сразу перешел к записи / воспроизведению, потому что из-за этого трудно увидеть в настройках, что заглушено / издевалось или просто выполняется код. Я считаю, что Rhino имеет несколько способов работы. В частности, вы можете использовать блок using(), чтобы изолировать настройки от других вызовов.