Какой тест написать?

Question

Я знаю, что это основной вопрос, но из-за недостатка моих знаний я не мог начать писать тест для своего приложения. Поэтому здесь я пытаюсь изучить и понять, что тестировать и как тестировать на основе моего сценария приложения.

Class MyController { 
    MyService service = new MyService(); 
    List<String> myList = service.generateSomeList(keyVal); 
    model.add("myList", myList); 
} 

Class MyService { 
    ThirdPatryService extService = new ThirdPatryService(); 
    MyDao dao = new MyDao(); 
    public List<String> generateSomeList(Long key) { 
    List<String> resultList = dao.fetchMyList(key); 
    extService.processData(resultList); //using 3rd party service to process result. It doesn't return anything. 
    return formattedList(resultList); 
    } 
    private List<String> formattedList(List<String> listToProcess) { 
    //do some formatting 
    } 
} 

Class MyDao { 
    List<String> fetchMyList(key) { 
     //Use DB connection to run sql and return result 
    } 
} 

Я хочу провести как тестирование модулей, так и интеграционное тестирование. Поэтому некоторые из моих вопросов:

1. Должен ли я выполнять модульное тестирование для MyDao? Я так не думаю, так как я могу проверить результат запроса, тестируя уровень сервиса.
2. Каковы возможные тестовые примеры для уровня обслуживания? Я могу придумать результат теста из db и функцию форматирования теста. Любой другой тест, который я пропустил?

3. При тестировании метода generateSomeList() это ОК, чтобы создать фиктивный список строк и проверить его на результат? Как и код ниже Я сам создаю список и тестирую себя. Это правильный/правильный способ написать тест?

   @Test 
   public void generateSomeListTest() { 
       //Step 1: Create dummy string list e.g. dummyList =["test1", "test2", "test3"] 
       //Step 2: when(mydao.fetchMyList(anyLong()).thenReturn(dummyList); 
       //Step 4: result=service.generateSomelist(123L); 
       //Step 5: assertEquals(result[i], dummyList[i]); 
   } 
   

4. Я не думаю, что мне нужно протестировать стороннее обслуживание, но я думаю, что должен убедиться, что он вызван. Это верно? Если да, то как я могу это сделать с Mockito?
5. Как убедиться, что служба thirdparty действительно обработала мои данные. Поскольку его тип возврата недействителен, как я могу выполнить тест, он действительно выполнил свою работу, например, как отправить письмо.
6. Должен ли я писать тест для контроллера, или я могу просто написать интеграционный тест.

Я очень благодарен, если бы вы могли ответить на этот вопрос, чтобы понять часть тестирования для приложения.

Спасибо.

Answer 1

1. Это не модульные тесты, но да, вы должны протестировать свои DAO. Одним из основных моментов в использовании DAO является то, что они относительно легко тестируются (вы храните некоторые тестовые данные в базе данных, затем вызываете метод DAO, который выполняет запрос, и проверяйте, возвращает ли он метод, который он должен вернуть), и что они упрощают тестирование сервисного уровня, насмехаясь над DAO. Вы должны определенно не использовать реальные DAO при тестировании услуг. Ue mock DAOs. Это позволит значительно упростить и значительно ускорить тесты обслуживания.

2. Проверка результатов работы БД является задачей теста DAO. Сервисный тест должен использовать макет DAO, который возвращает жестко запрограммированные результаты, и проверяет, что служба не знает, что она должна делать с этими жестко закодированными результатами (форматирование в этом случае)

3. Да, это нормально.

4. Обычно достаточно заглушить зависимости. Проверка того, что они были вызваны, часто является избыточной. В этом случае это может быть хорошей идеей, поскольку служба третьей стороны ничего не возвращает. Но это запах кода. Почему он ничего не возвращает? См. Метод verify() в Mockito. Это самый первый момент в документации Mockito: http://docs.mockito.googlecode.com/hg/latest/org/mockito/Mockito.html#1

5. Служба третьей стороны должна быть протестирована отдельно и, таким образом, быть надежной. Поэтому вы должны предположить, что он делает то, что говорит его документация. Тест на A, который использует B, не должен тестировать B. Только A. Тест B тестов B.

6. Единичный тест обычно проще писать и быстрее выполнять. Также легче тестировать угловые шкафы с модульными испытаниями. Интеграционные тесты должны быть более крупнозернистыми.

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