Есть ли смысл проверять это? (Шаблон репозитория) - PullRequest
2 голосов
/ 18 июля 2009

Приступая к работе с 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);
}

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

Ответы [ 4 ]

3 голосов
/ 18 июля 2009

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

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

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

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

0 голосов
/ 18 июля 2009

Могу ли я предложить альтернативное решение ... Столь же простой, как ваш репозиторий (если это все те же методы, за исключением того, что они возвращают), почему бы вам не создать базовый класс, используя 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 голосов
/ 18 июля 2009

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

Привет.

0 голосов
/ 18 июля 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...