Весенние тестовые модули Junit для логики busienss и соединений с БД

Question

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

Контроллер имеет:

  @RequestMapping(value = "/v1/abc/def", method = RequestMethod.GET, produces = MediaType.APPLICATION_JSON_VALUE)
    public ServiceResponse<Map<String, List<ClicksReply>>> getAbcCall(@RequestParam(value = "Id") String Id,
                                                                                   @RequestParam(value = "Tag") List<String> Tag) throws SQLException {
        Map<String, List<ClicksReply>> clicks = mysqlService.getReplyCount(pageId, notificationTag);
        return new ServiceResponse<>(HttpStatus.OK, clicks);
    } 

mysqlService.getReplyCount выглядит следующим образом:

    public Map<String, List<ClicksReply>> getReplyCount(String pageId, List<String> notificationTag) {
            String notificationIds = getStringForInQuery(notificationTag);
            try (PreparedStatement preparedStatement = connection.prepareStatement(String.format(GET_CLICK_COUNT, notificationIds))) {
                Map<String, List<Clicks
Reply>> mapNotifsButtonCount = new HashMap<>();
                preparedStatement.setString(1, pageId);
                ResultSet resultSet = preparedStatement.executeQuery();
                while (resultSet.next()) {

                    ClicksReply reply = new ClicksReply();

                    Integer buttonId = resultSet.getInt(2);
                    Integer clickCount = resultSet.getInt(3);

                    reply.setButtonId(buttonId);
                    reply.setCount(clickCount);
                    String tag = resultSet.getString(1);


                    if (!mapNotifsButtonCount.containsKey(tag)) {
                        List<ClicksReply> clicksReplies = new LinkedList<>();
                        mapNotifsButtonCount.put(tag, clicksReplies);
                    }
                    List<ClicksReply> existinglist = mapNotifsButtonCount.get(tag);
                    existinglist.add(reply);
                }
                resultSet.close();
                preparedStatement.close();
                return mapNotifsButtonCount;
            } catch (SQLException exception) {
                return null;
            }
        }

Я новичок в Java Stack и попытался написать модульный тест после ознакомления с некоторыми основами, вот как далеко я продвинулся:

@RunWith(SpringRunner.class)
@WebMvcTest(value = StatsController.class, secure = false)
public class StatsTest {
    @Autowired
    private MockMvc mockMvc;

    @MockBean
    private MysqlService mysqlService;

    @Test
    public void getReplyCount() throws Exception {
        Map<String, List<ClicksReply>> mapClicksReply = new HashMap();
        Mockito.when(
                mysqlService.getQuickReplyCount(
                        Mockito.any(String.class), Mockito.anyListOf(String.class)
                )
        ).thenReturn(mapClicksQuickReply);


        RequestBuilder requestBuilder = MockMvcRequestBuilders.get(
                "/v1/abc/def")
                .param("Id", Mockito.anyString())
                .param("Tag", Mockito.anyString())
                .accept(
                MediaType.APPLICATION_JSON);

        mockMvc.perform(requestBuilder).
                andExpect(jsonPath("$.httpStatusCode").value(200))
                .andExpect(jsonPath("$.errorMessage").value(IsNull.nullValue()))
                .andDo(print());


    }

}

Каким должен быть следующий шаг, чтобы на самом деле «модульно проверить» бизнес-логику, Соединение с БД и результаты запроса?То, что я сделал до сих пор, больше похоже на высокоуровневый API-тест, проверяющий состояние.

Я не уверен в направлении, чтобы проверить бизнес-логику сейчас.

Answer 1

Я думаю, что нет «правильного» ответа, но я бы сначала разделил метод getReplyCount, потому что на данный момент его сложно проверить.Этот метод в настоящее время делает несколько вещей:

• готовит запрос
• извлекает данные с подготовленным оператором
• отображает данные в ClicksReply класс
• группирует элементы по тегам

С гораздо меньшей областью вы можете намного проще тестировать различные сценарии, такие как:

• действительные / недействительные входные параметры
• построение запроса
• сбой при выполнении запроса
• различные проблемы с отображением
• правильная группировка элементов

Также на вашем API вы тестируетеможно добавить больше сценариев, таких как ошибка, неверный ввод и т. д.

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

Надеюсь, это помогло.

С уважением, Випу