Как протестировать Spring веб-метод?

104

27 декабря 2020, 09:40

В этом методе происходит реверс слова с использованием рекурсии и без неё.

Вопрос: как можно протестировать метод inverseString?

 private Jinjava templateRender = new Jinjava();

 @PostMapping("/reverseString")
@ResponseBody
public String inverseString(@RequestParam("text") String text,
                            @RequestParam(value = "tailRecurse", defaultValue = "false") Boolean useTaleRecurse)
{
    Map<String, Object> map = Maps.newHashMap();
    if (useTaleRecurse)
        map.put("detail", reverseString("", text, text.length()));
    else
        map.put("detail", new StringBuffer(text).reverse().toString());
    return templateRender.render(getTemplate("index.html"), map);
}

 private String reverseString(String accumulator,String source, int size)
{
    if (size == 0)
        return accumulator;
    return reverseString(accumulator.concat(source.substring(size - 1, size)), source, size - 1);
}

Answer 1

Вы можете использовать MVC Test Framework. Он позволяет протестировать всю MVC-инфраструктуру, например @RequestMapping, @ResponseBody и т.п.

Очень простой пример использования фреймворка. Здесь будет вызывать метод inverseString и проверка на получение ответа с кодом 200 + вывод ответа:

...
@Test
public void getPersons() throws Exception {
    this.mockMvc.perform(post("/reverseString?text=SStringS&tailRecurse=true"))
      .andExpect(status().isOk())
      .andDo(print());
}
...

Возможности фреимворка гораздо больше, поэтому я советую прочитать вам документацию по ссылке выше.

Источник.

Answer 2

Вам уже ответили про тестовые фреймворки, добавлю свои 5 копеек:

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

Т. е. грубо говоря нет смысла тестировать как работает спринг, если Вы хотите протестировать логику и наоборот, тестировать логику, когда Вы проверяете что API такой, как Вы ожидаете

Такие тесты надо делить на 2 независимых группы:

Тесты API должны зафиксировать какие аргументы принимает и какие аннотации содержит тестируемый метод .

Так же нужно проверить что управление передается куда следует.

А вот логику, которую вызывает метод торчащий наружу я бы вынес в отдельный метод и Unit тестами покрывал бы его.

Раздедение такого характера - позволяет тестам работать быстрее и дает такое же разделение на api и логику, какую Вы надеюсь привыкли видеть в коде программы.

Код теста порой должен быть даже более читаем чем код программы, потому что чуть что - падает тест и открываете и читаете в первую очеред Вы именно его.

А вообще конечно это все не догма :), не зря я там написал "Я считаю"