Как выполнить юнит-тестирование по невежеству - PullRequest
Новая
       48

Как выполнить юнит-тестирование по невежеству

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

Я работаю над новым проектом, где я активно пытаюсь чтить упорство невежества.Например, на моем уровне обслуживания я извлекаю сущность из своего ORM и вызываю подпрограмму, определенную для сущности, которая может или не может вносить изменения в сущность.Затем я полагаюсь на мой ORM, чтобы определить, был ли объект изменен или нет, и он делает необходимые вставки / обновления / удаления.

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

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

mockRepository.Verify(mr => 
  mr.SaveOrUpdate(It.Is<MyEntity>(x => 
    x.Id == 123 && x.MyProp == "newvalue")), Times.Once());

Правильно ли я подхожу к постоянному невежеству?Есть ли лучший способ для модульного тестирования послеоперационного состояния моих объектов, когда я не вызываю явно метод сохранения хранилища?

Если это помогает, я использую ASP.NET MVC 3, WCF,NHibernate и NUnit / Moq.Мои модульные тесты обращаются к действиям моего контроллера, передавая экземпляры моих классов обслуживания (которые создаются с помощью проверенных репозиториев).

Ответы [ 2 ]

0 голосов
/ 25 октября 2011

Как ни странно, я просто наткнулся на решение, и оно действительно простое. 

[Test]
public void Verify_Widget_Description_Is_Updated()
{
  // arrange
  var widget = new Widget { };
  mockWidgetRepo.Setup(mr => mr.GetWidget()).returns(widget);

  var viewModel = new WidgetVM { };
  viewModel.Description = "New Desc";  

  // act
  var result = (ViewResult)controller.UpdateWidget(viewModel);

  // assert
  Assert.AreEqual("New Desc", widget.Description);
}

Это не идеально, но я могу предположить, что если widget.Description соответствует значению, которое я присвоил своей модели представления, тоORM сохранит это изменение, если не будет вызвано evict.

ОБНОВЛЕНИЕ: Просто придумали другое альтернативное решение.Я создал функцию ObjectStateAssertionForTests (Object obj) в моем базовом хранилище, которая ничего не делает.Я могу вызвать эту функцию в своем коде, а затем проверить ее в своих модульных тестах. 

mockRepository.Verify(mr => 
  mr.ObjectStateAssertionForTests(It.Is<MyEntity>(x => 
    x.Id == 123 && x.MyProp == "newvalue")), Times.Once());
0 голосов
/ 06 июля 2011

Вы подходите к этому правильно, потому что у вас есть интерфейс, представляющий ваш репозиторий и проходящий подделку в ваших тестах, я предпочитаю использовать симулятор в памяти для своих репозиториев вместо использования mocks, потому что я считаю, что реализации заглушки имеют тенденцию ксделать мои тесты менее хрупкими, чем использование mock / verify (в соответствии с mocks - это не заглушки, ссылки на которые приведены выше).Если в вашем хранилище есть методы Add / Find / Delete, моя реализация в памяти перенаправит их в список участников, а затем save установит свойство SavedList, которое я могу утверждать в своих тестах.

...