Новый синтаксис для Rhino Mocks

Question

Я немного пытаюсь понять, как работает новый синтаксис AAA в Rhino Mocks. Большинство моих тестов выглядят так:

    [Test]
    public void Test()
    {
        //Setup
        ISth sth= mocks.DynamicMock<ISth>();

        //Expectations
        Expect.Call(sth.A()).Return("sth");

        mocks.ReplayAll();
        //Execution
        FunctionBeingTested(sth);
        //...asserts, etc

        //Verification
        mocks.VerifyAll();
    }

Как бы это выглядело при использовании синтаксиса AAA?

Answer 1

Скорее всего так:

[Test]
public void Test()
{
    // Arrange
    ISth sth= MockRepository.GenerateMock<ISth>();

    sth
      .Stub(x => x.A())
      .Return("sth");

    // Act
    FunctionBeingTested(sth);

    // Assert
}

Чтобы по-настоящему воспользоваться новым синтаксисом AAA, вам нужно немного передумать. Я пытаюсь объяснить.

В моем предложении есть существенное различие: здесь нет "Expect-Verify". Поэтому я предлагаю не ожидать вызова, потому что есть возвращаемое значение. Я предполагаю, что метод не может пройти тест, когда он не вызвал sth.A, потому что он пропустит правильное возвращаемое значение. Это потерпит неудачу, по крайней мере, один из других утверждает.

Это на самом деле хорошая вещь.

• вы можете переместить заглушку в TestInitialize, это не повредит, если заглушенный метод не вызывается в тесте (это не ожидание). Ваши тесты станут короче.
• Ваш тест не знает, "как" работает тестируемая система, вы только проверяете результаты. Ваши тесты станут более понятными.

---

Есть еще один сценарий, в котором вам действительно нужно проверить, был ли вызван метод на макете. Главным образом, если он возвращает void. Например: событие должно было быть запущено, транзакция совершена и так далее. Для этого используйте AssertWasCalled:

[Test]
public void Test()
{
    // Arrange
    ISth sth= MockRepository.GenerateMock<ISth>();

    // Act
    FunctionBeingTested(sth);

    // Assert
    sth
      .AssertWasCalled(x => x.A());
}

Примечание: нет возвращаемого значения, поэтому нет заглушки. Это идеальный случай. Конечно, вы могли бы иметь, Stub и AssertWasCalled.

---

Существует также Expect и VerifyAllExpectations, которые фактически ведут себя как старый синтаксис. Я бы использовал их только тогда, когда вам нужны Stub и AssertWasCalled в одном и том же тесте, и у вас есть ограничения полных аргументов, которые вы не хотите писать дважды. Обычно избегают Expect и VerifyAllExpectations

Answer 2

пример из блога Айенде:

[Test]
public void WhenUserForgetPasswordWillSendNotification_UsingExpect()
{
    var userRepository = MockRepository.GenerateStub<IUserRepository>();
    var notificationSender = MockRepository.GenerateMock<INotificationSender>();

    userRepository.Stub(x => x.GetUserById(5)).Return(new User { Id = 5, Name = "ayende" });
    notificationSender.Expect(x => x.Send(null)).Constraints(Text.StartsWith("Changed"));

    new LoginController(userRepository, notificationSender).ForgotMyPassword(5);

    notificationSender.VerifyAllExpectations();
}

Изменения в вашем тесте

[Test]
    public void Test()
    {
        //Arrange
        var sth= MockRepository.GenerateMock<ISth>();  
        sth.Expect(x=>sth.A()).Return("sth");

        //Act
        FunctionBeingTested(sth);

        //Assert
        sth.VerifyAllExpectations();
    }

Но это всего лишь длинный выстрел. Написал так, как я подозреваю.