TDD - Сколько ты тестируешь?

Question

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

что-то похожее на следующее;

public class UserRepository : IUserRepository
{
    public IQueryable<User> GetUsers()
    {
    // do stuff
    }
}

public class UserService 
{
    public IList<User> GetUserById
    {
        var rep = new UserRepository();
        var users = rep.GetUsers();
        // do business logic
        return users.ToList();
    }
}

Будете ли вы тестировать как UserService, так и UserRepository, или, по вашему мнению, достаточно будет протестировать только Сервис? Я полагаю, так как сервис использует репозиторий, это должно быть весело, но это убивает покрытие кода.

Answer 1

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

Answer 2

протестируйте требуемые функции:

• некоторые функции могут находиться в одном классе
• некоторые могут проживать в другом классе
• некоторым могут потребоваться оба класса

из вашего описания похоже, что вы можете определить функции, так что вы можете в значительной степени оправдать тестирование всего, что вам нравится; -)

если вам нужна минимальная эффективность TDD, протестируйте только текущую функцию и перейдите на . Покрытие кода не имеет значения для TDD; это показатель модульного тестирования (сомнительной ценности)

[пусть начнется снижение голосов! ; -)]

Answer 3

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

Отредактируйте в ответ на комментарий: Если вы еще не написали код, я бы сначала написал тесты для UserService, потому что это конечная цель вашего приложения. Затем, когда я написал код для прохождения тестов UserService, я породил тесты репозитория. Эти тесты в конечном итоге становятся спецификацией хранилища на тот случай, если вы захотите использовать его позже.

Answer 4

Запись модульных тестов службы путем макетирования репозитория для тестирования бизнес-логики в Сервисе и для тестирования различных сценариев репозитория, таких как Исключение, тестирование возвращаемых значений и т. Д. Некоторые среды моделирования, такие как EasyMock, требуют интерфейс репозитория, в то время как другие, как Mockito, этого не делают. Таким образом, ваши Сервисные тесты не будут иметь доступа к БД и будут выполняться быстрее.

Напишите репозиторий тестов для проверки всех ваших взаимодействий с БД. Используйте набор данных / осветительные приборы блока БД для тестовых данных, чтобы убедиться, что логика БД реализована правильно.

Кроме того, вы можете захотеть написать интеграционные тесты для своего класса Service, где к БД обращаются без репозитория.

Answer 5

Как уже упоминали другие, если UserService - это все, что увидят клиенты вашего приложения, я бы сейчас только протестировал это и сделал бы UserRepository недоступным для ваших клиентов (например, сделать его внутренним). Таким образом, вы получите хорошее покрытие кода даже без индивидуального тестирования классов.

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

Answer 6

Если вы следуете процессу TDD, как следует из заголовка вопроса, у вас не будет классов UserRepository и UserService, если они не были протестированы.

Существует eXtreme Programming, говорящее: « Тестируйте все, что может сломать », так что вам лучше тестировать их все, чтобы вы могли быть уверены в своем коде.

Answer 7

У вас есть два варианта:

• Модульные тесты - в этом случае вы тестируете каждый компонент изолированно без доступа к службам, диску, базам данных, активному каталогу и т. Д. Это достигается за счет того, что ваши тесты выступают в роли драйвера и заглушают / высмеивают используемые классы по классу, который вы тестируете.

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

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

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

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

Answer 8

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