Модульное тестирование гарантирует, что один метод вызывает другой метод - PullRequest
Новая
       23

Модульное тестирование гарантирует, что один метод вызывает другой метод

1 голос
/ 11 июля 2011 
[HttpPost]
public ActionResult Create(Car car)
{
   _repository.CreateCar(car);
   _repository.UpdateRegistrationDetails(car);
}

Я хочу написать модульный тест, чтобы Create вызывал CreateCar и UpdateRegistrationDetails. Не имеет значения, что происходит в этих методах, а только то, что они вызываются. Может кто-нибудь сказать, пожалуйста, как это сделать? Нужно ли использовать для этого фальшивый фреймворк? У меня установлен RhinoMocks для использования. Вы используете Expect в RhinoMocks?

Ответы [ 3 ]

4 голосов
/ 11 июля 2011

Снова используя Moq, я думаю, что вместо этого вам нужно смоделировать репозиторий (при условии, что имена здесь, конечно) 

var mock = new Mock<IRepository>();

var controller = new Controller(mock.Object); //assuming this is how you create it

var car = new Car();
controller.Create(car);

mock.Verify(x => x.CreateCar(car));
mock.Verify(x => x.UpdateRegistrationDetails(car));

Нет необходимости в Setup или Expect, так как проверенные методы ничего не возвращают

[EDIT] Вот пример Rhino.Mocks 

var mock = MockRepository.GenerateStub<IRepository>();

var controller = new Controller(mock); //assuming this is how you create it

var car = new Car();
controller.Create(car);

mock.AssertWasCalled(x => x.CreateCar(car));
mock.AssertWasCalled(x => x.UpdateRegistrationDetails(car));
1 голос
/ 14 июля 2011

Относительно использования Expect() в RhinoMocks. Я предпочитаю использовать заглушки и методы 'Stub ()' или AssertWasCalled() как можно больше. Expect() используется в тех случаях, когда больше ничего не работает.

1 голос
/ 11 июля 2011

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

public class RepoUnderTest : Repo
{
    public bool UpdateRegistrationDetailsCalled = false;
    public override void UpdateRegistrationDetails(Car car)
    {
        base.UpdateRegistrationDetails(car);
        UpdateRegistrationDetailsCalled = true;
    }
}

тогда вы можете проверить что-то похожее на 

[HttpPost]
public ActionResult Create(Car car)
{
   // Arrange
   var _repository = new RepoUnderTest();

   // Act
   _repository.CreateCar(car);

   // Assert
   Assert.IsTrue(_repository.UpdateRegistrationDetailsCalled);
}

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

...