Возвращение пустых списков по умолчанию с помощью Rhino Mocks - PullRequest
Новая
       53

Возвращение пустых списков по умолчанию с помощью Rhino Mocks

7 голосов
/ 12 февраля 2009

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

Поскольку Rhino Mocks возвращает значение по умолчанию для объекта, которое является нулевым для списков и массивов, мне часто приходится либо добавлять нулевые проверки обратно, либо устанавливать mock с ожиданиями для возврата списков.

Есть ли способ настроить или расширить Moh Rhino с таким поведением? 

var repositoryMock = MockRepository.GenerateMock<ICustomerRepository>();
IList<Customer> customers = repositoryMock.getCustomers();

Assert.IsNotNull(customers);
Assert.AreEqual(0, customers.Count );

Ответы [ 3 ]

0 голосов
/ 13 февраля 2009

Я думаю, что изменение поведения макетов по умолчанию для возврата значений, отличных от значений по умолчанию, было бы рискованным шагом.

Что бы произошло, если бы в ваших реальных реализациях ICustomerRepository была ошибка, из-за которой она не возвращала пустой список и вместо этого возвращала ноль?

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

Почему? Потому что ваши классы, попавшие в ICustomerRepository, неправильно обрабатывали нули.

Я бы предпочел быть явным и установить в тесте ожидание возврата пустого IList из метода getCustomers (), чем что-то «волшебное» внутри макета. Зачем? Потому что это улучшает читабельность, и код работает в соответствии с тем, что другие разработчики, которые могут быть не так знакомы с Rhino, ожидают, что он будет работать. то есть метод без ожидания возвращает значение по умолчанию.

0 голосов
/ 15 февраля 2009

Оказывается, что такое поведение возможно с Moq , пока возвращаемый объект IEnumerable. Сданы следующие тесты: 

[Test]
public void EmptylListTest()
{
    var repositoryMock = new Mock<ICustomerRepository>();

    IEnumerable<Customer> customers = repositoryMock.Object.GetCustomers();

    Assert.IsNotNull(customers);
    Assert.AreEqual(0, customers.Count());
}

[Test]
public void EmptyArrayTest()
{
    var repositoryMock = new Mock<ICustomerRepository>();

    Customer[] customerArray = repositoryMock.Object.GetCustomerArray();

    Assert.IsNotNull(customerArray);
    Assert.AreEqual(0, customerArray.Length);
}

public interface ICustomerRepository
{
    IEnumerable<Customer> GetCustomers();
    Customer[] GetCustomerArray();
}
0 голосов
/ 12 февраля 2009

В Rhino Mocks нет ничего, чтобы автоматически решить вашу проблему. Самое простое решение - просто настроить метод расширения / утилиты для каждого типа, который использует SetupResult (или repeat.any) для настройки значения по умолчанию.

Вы всегда можете быть хитрыми и перечислять членов, проверяя ILists / Arrays и динамически настраивая макеты - это зависит от того, сколько типов у вас есть, сколько типов вы можете выделить для этого вспомогательного метода.

Удачи!

...