Мой первый в истории модульный тест

Я считаю себя довольно поздним. Я был на втором году своей карьеры, и мой первый модульный тест состоялся несколько дней назад. Недавно я присоединился к команде бэкэнда, и у них есть политика покрытия тестами. Из-за этой политики каждый разработчик, работающий над определенной задачей, должен выполнять модульные тесты для выполнения своей задачи. Мне всегда нравилась идея иметь тесты в качестве друга, которые повышают вашу уверенность в своей работе и помогают выявлять ошибки, быстро облегчая и улучшая вашу работу. В любом случае, моей первой задачей в команде бэкэнда было предоставить простой URL-адрес GET. Мы используем spring в качестве фреймворка разработки, Mockito в качестве фреймворка для насмешек и JUnit для тестирования. В этом посте я хотел бы поделиться с вами своим первым тестом.

Согласно Википедии, это “метод тестирования программного обеспечения, с помощью которого отдельные блоки исходного кода, наборы одного или нескольких модулей компьютерной программы вместе с соответствующими контрольными данными, процедурами использования и операционными процедурами тестируются, чтобы определить, подходят ли они для использования”

Для модульного тестирования вашего приложения вы должны следовать принципу проектирования, заключающемуся в наличии небольших модульных модулей, которые вы можете тестировать. Если вы собираетесь протестировать небольшой компонент вашего приложения. он должен быть изолирован от всех других компонентов. Вот тут-то и появляется Мокито. Вот где вам придется издеваться и абстрагироваться от любых внешних зависимостей. Я вижу это так, что модульное тестирование следует методологии “разделяй и властвуй”:

1. Изолируйте свой код, издеваясь над внешними зависимостями
2. Подумайте о каждом возможном сценарии
3. Напишите свои тесты для этого конкретного подразделения, охватывающие все сценарии
4. Делайте это до тех пор, пока не будет протестировано каждое устройство в вашем приложении

Это мое первое задание весной. Я выбираю самый простой, какой только могу достать. Приведенный ниже код представляет собой контроллер, который извлекает ресурс с уровня обслуживания, и на основе ответа контроллер будет отвечать кодом ответа 200 или 404.

@RequestMapping(method = RequestMethod.GET)
public ResponseEntity> getAllResource() {
    List resourceList = resourceService.getAllResource();

    if (resourceList.size() > 0) {
        return new ResponseEntity>(resourceList, null, HttpStatus.OK);
    }
    return new ResponseEntity>(null, null, HttpStatus.NOT_FOUND);
}

Очень просто, не так ли? Если вы подумаете об этом, вся логика в приведенном выше коде сводится к условию “ЕСЛИ”. И это именно то, что мы собираемся проверить.

Хорошо, давайте выполним описанные выше действия:

1. Изолировать: В этом случае нам нужно изолировать контроллер, имитируя вызов уровня обслуживания. Таким образом, мы делим цикл на блоки, а затем тестируем каждый блок независимо. В этом посте я только тестирую блок контроллера.
2. Охватить все сценарии: В этом случае у нас есть 2 варианта: либо нам есть что вернуть, либо нет. Если список ресурсов, возвращаемых издевательским уровнем сервиса, не пуст, то вывод должен быть 200. Если нет, то вывод должен быть 404.
3. Написание тестов, охватывающих каждый сценарий:

Либо сервисный уровень возвращал непустой список, либо контроллер возвращал код состояния 200

@Test
public void testGetAllResourceSuccess() {
    List resourceList = new ArrayList();
    resourceList.add(new Resource());

    // Here we mock the service layer function and set the response to a non-empty list.
    Mockito.when(resourceServiceImpl.getAllResource()).thenReturn(resourceList);
    try {
        // Then we expect the response to be a 200
        mockMvc.perform(get("/resource")).andExpect(status().isOk());
    } catch (Exception e) {}
}

Или уровень обслуживания вернул пустой список, контроллер затем вернул бы код состояния 404

@Test
public void testGetAllResourceFail() {
    List resourceList = new ArrayList();
    // Here we mock the service layer function and set the response to an empty list.
    Mockito.when(resourceServiceImpl.getAllResource()).thenReturn(resourceList);
    try {
        // Then we expect the response to be a 404
        mockMvc.perform(get("/resource")).andExpect(status().isNotFound());
    } catch (Exception e) {}
}

Выглядит легко, просто и прямолинейно, не так ли? Ну, вот как проходят модульные тесты. Сначала я чувствовал, что этого не может быть. Я чувствовал, что это слишком просто, что я никогда на самом деле не потерплю неудачу. Затем, после некоторого исследования, все обрело смысл. На самом деле вам не нужно тестировать весь цикл в одном тестовом примере. В каждом тестовом примере вы охватываете небольшую единицу. Выполнение этого везде означает, что каждый бит сам по себе работает правильно. Вот почему действительно важно охватить каждую единицу вашего проекта.

Счастливого кодирования 🔥 🔥

Оригинал: “https://dev.to/bassemmohamed/my-first-ever-unittest-3g0d”