Я знаком с основными принципами TDD, являются:Каков наилучший подход для модульного тестирования, когда у вас есть интерфейсы с фиктивными и реальными реализациями?
- Писать тесты, они будут не в состоянии из-за отсутствия реализации
- Написать базовую реализацию, чтобы сделать тесты пройдены
- Refactor код
Однако я немного запутался относительно того, где сопряжены интерфейсы и реализация. Я создаю веб-приложение Spring в свое свободное время, и вместо того, чтобы идти в пушки, я хотел бы понять, как я могу лучше проверить интерфейсы/реализации, возьмите этот простой пример кода, который я здесь создал:
public class RunMe
{
public static void main(String[] args)
{
// Using a dummy service now, but would have a real implementation later (fetch from DB etc.)
UserService userService = new DummyUserService();
System.out.println(userService.getUserById(1));
}
}
interface UserService
{
public String getUserById(Integer id);
}
class DummyUserService implements UserService
{
@Override
public String getUserById(Integer id)
{
return "James";
}
}
Я создал интерфейс UserService, в конечном счете, будет реальное осуществление этого, что будет запрос к базе данных, однако для того, чтобы получить приложение от земли я заменил DummyUserService реализации, которая будет только возврат некоторые статические данные на данный момент.
Вопрос: Как я могу реализовать стратегию тестирования для вышеуказанного?
я мог бы создать тестовый класс под названием DummyUserServiceTest и тест, когда я звоню getUserById() он будет возвращаться James, кажется довольно простым, если не пустая трата времени (?).
Впоследствии я также мог создать тестовый класс RealUserService, который будет проверять, что getUserById() возвращает имя пользователя из базы данных. Это та часть, которая меня смущает, делая это, по сути, не выходит за пределы единичного теста и становится более тестом на интеграцию (с ударом по БД)?
Вопрос (улучшенный, немного): При использовании интерфейсов с фиктивными/закодированными и реальными реализациями, какие части должны быть проверены на единицу, а какие части могут быть оставлены непроверенными?
Я провел несколько часов погуглить на эту тему прошлой ночью, и главным образом найдены либо учебники на том, что TDD является или примеры того, как использовать JUnit, но ничего в сферах консультирования, что на самом деле должны быть проверены. Это вполне возможно, хотя я не искал достаточно трудно или не искал правильную вещь ...