Есть ли смысл проверять это? (Шаблон репозитория)

2

Приступая к работе с TDD и шаблоном репозитория, мне интересно, не имеет ли это никакого смысла тестировать это...

Используя шаблон репозитория, у меня есть этот интерфейс:

public interface ICustomerRepository
{
    IList<Customer> List();
    Customer Get(int id);
}

У меня есть 50 разных объектов, поэтому 50 различных интерфейсов/реализаций репозитория.

Мой вопрос в том, правильно ли протестировать каждый репозиторий, высмеивая интерфейс, например:

[TestMethod]
public void List_Should_Return_Two_Customers()
{
    // Arrange
    var customerr = new List<Customer>();
    customer.Add(new Customer());
    customer.Add(new Customer());

    var repository = new Mock<ICustomerRepository>();
    repository.Setup(r => r.List()).Returns(customer);

    // Assert
    Assert.AreEqual(2, repository.Object.List().Count);
}

[TestMethod]
public void Get_Should_Return_One_Customer()
{
    // Arrange
    var customer = new List<Customer>();
    customerr.Add(new Customer() { Id = 1 });
    customerr.Add(new Customer() { Id = 2 });

    var repository = new Mock<ICustomerRepository>();
    repository.Setup(r => r.Get(1)).Returns(customer.Where(w => w.Id == 1).First());

    // Assert
    Assert.IsTrue(repository.Object.Get(1).Id == 1);
}

Есть ли смысл тестировать фальшивую реализацию этих интерфейсов? Для меня это не так.

  • 0
    для меня это не имеет смысла, что вы должны использовать слово GOT вместо HAVE
  • 0
    С 50 сущностями вы наверняка сможете уменьшить количество репозиториев. У меня есть домен из 65 объектов, но у меня есть только 7 репозиториев для них ... Я моделирую репозитории после доменных "хабов" или основных понятий, а не для каждого объекта.
Показать ещё 1 комментарий
Теги:
unit-testing
repository

4 ответа

3
Лучший ответ

Нет, это не имеет смысла. Очевидно, вы должны тестировать только реализации, а не интерфейсы. В интерфейсе нечего тестировать.

Единственное, что тестируется в ваших примерах - это насмешливая структура, список .NET и некоторые методы расширения LINQ. Нет необходимости проверять их, кто-то еще позаботится об этом.

Может быть, намерение состояло в том, чтобы предоставить модульные тесты для того, что интерфейс существует и имеет определенные методы? В этом случае тесты по-прежнему не нужны. Это неявно тестируется на тесты для другого кода, который опирается на декларацию интерфейса.

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

0

Другие правы. Вы не можете тестировать интерфейсы. Вы на самом деле проверяете насмешки, и это не имеет смысла. Обычно я тестирую репозитории против базы данных, поэтому для них не так много модульного тестирования. И для проверки чего-то выше, я издеваюсь над ними. Имейте в виду, что 50 типов объектов не означают 50 репозиториев.

С уважением.

0

Можно ли предложить альтернативное решение... Насколько прост, как ваш репозиторий (если они все те же методы, за исключением того, что они возвращают), почему бы вам не сделать базовый класс с помощью Generics. Тогда вам нужно будет только проверить базовый класс.

public interface IRepository<TEntity> where TEntity : class
{
    IList<TEntity> List();
    TEntity Get(int id);
}

public abstract class BaseRepository<TEntity> : IRepository<TEntity> where TEntity : class
{
    IList<TEntity> List()
    {
        //DataContext.GetTable<TEntity>().ToList();
    }

    TEntity Get(int id)
    {
        //Might have to do some magic here... you can use reflection or create
        //an abstract method that the derived class must override that returns
        //a delegate id selector.
    }
}
  • 0
    У меня были некоторые проблемы с созданием общих репозиториев. Это сработало, но в итоге оказалось не так элегантно, как мне бы хотелось. Но для метода Get (id) я бы порекомендовал решение «где TEntity: IdEntity» или аналогичное, где IdEntity - это реальный класс, имеющий свойство Id и другую информацию о персистентности.
0

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

  • 0
    Итак, два теста, которые я написал, на самом деле верны? Было бы хорошей идеей создать фальшивые классы репозитория, такие как FakeCustomerRepository с собственно данными о клиентах? И затем использовать эту реализацию в моих тестах?
  • 1
    Да, но вы не должны проверять издевательства. (Это то, что Томми спрашивает, должен ли я проверить издевательства; ответ для меня - нет). Я бы действительно протестировал реальные реализации, но не поддельные.
Показать ещё 3 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню