Как вы издеваетесь над своими репозиториями?

Question

Я использую Moq, чтобы издеваться над моим repositories. Однако недавно кто-то сказал, что они предпочитают создавать жесткоспециализированные тестовые реализации своих интерфейсов репозитория.

Каковы плюсы и минусы каждого подхода?

Редактировать: уточнено значение репозитория со ссылкой на Фаулер.

Answer 1

Я вообще вижу два сценария с хранилищами. Я прошу чего-то, и я понял, или я прошу чего-то, и его нет.

Если вы издеваетесь над своим репозиторием, это означает, что вы тестируете систему (SUT) - это то, что использует ваш репозиторий. Поэтому вы обычно хотите проверить, что ваш SUT ведет себя правильно, когда ему предоставляется объект из репозитория. И вы также хотите проверить, что он правильно справляется с ситуацией, когда вы ожидаете получить что-то обратно и не хотите, или не уверены, что вы собираетесь что-то вернуть.

Твердые закодированные двойные коды одобрены, если вы проводите интеграционное тестирование. Скажем, вы хотите сохранить объект, а затем вернуть его обратно. Но это проверяет взаимодействие двух объектов вместе, а не только поведение SUT. Это две разные вещи. Если вы начинаете кодирование поддельных репозиториев, вам нужны модульные тесты для этих целей, иначе вы в конечном итоге основываете успех и неудачу своего кода на непроверенном коде.

Это мое мнение о Mocking vs. Test Doubles.

Answer 2

Я предполагаю, что под «репозиторием» вы подразумеваете DAO; если нет, то этот ответ не будет применяться.

В последнее время я делал «в памяти» «макет» (или тестирование) реализаций моего DAO, которые в основном работают с данными (списком, картой и т. Д.), Переданными в конструктор mock. Таким образом, единичный тестовый класс может свободно использовать любые данные, необходимые для тестирования, изменять его и т. Д., Не заставляя все модульные тесты, работающие в DAO «в памяти», кодироваться для использования одних и тех же тестовых данных.

Один плюс, который я вижу в этом подходе, заключается в том, что если у меня будет дюжина модульных тестов, которые должны использовать один и тот же DAO для их теста (например, для ввода в тестируемый класс), мне не нужно помните все детали тестовых данных каждый раз (как если бы «макет» был жестко запрограммирован) - модульный тест сам создает тестовые данные. С другой стороны, это означает, что каждый юнит-тест должен потратить несколько строк на создание и подключение своих тестовых данных; но это маленький недостаток для меня.

Пример кода:

public interface UserDao { 
    User getUser(int userid); 
    User getUser(String login); 
} 

public class InMemoryUserDao implements UserDao { 

    private List users; 

    public InMemoryUserDao(List users) { 
     this.users = users; 
    } 

    public User getUser(int userid) { 
     for (Iterator it = users.iterator(); it.hasNext();) { 
      User user = (User) it.next(); 
      if (userid == user.getId()) { 
       return user; 
      } 
     } 

     return null; 
    } 

    public User getUser(String login) { 
     for (Iterator it = users.iterator(); it.hasNext();) { 
      User user = (User) it.next(); 
      if (login.equals(user.getLogin())) { 
       return user; 
      } 
     } 

     return null; 
    } 
} 

Answer 3

SCNR: «?! Вы называете себя вместилищем я видел спичечные коробки с большей пропускной способностью»