Источник: Nuances of Programming
Шаг 1. Установка плагина и импорт проекта
Плагин для IntelliJ IDEA полностью бесплатен для разработки программ с открытым исходным кодом. Чтобы установить его, перейдите в меню “Настройки” (Preferences) IntelliJ IDEA, в его левой части выберите Плагины (Plugins) и найдите через поиск Diffblue Cover, как показано ниже.
После завершения установки и при наличии существующего проекта, который импортирован в IntelliJ IDEA, плагин начнет индексировать и анализировать всю кодовую базу (т. е. классы, зависимости и т. д.) в качестве фоновой задачи. Это может занять некоторое время в зависимости от её размера и сложности.
Вы также можете дополнительно настроить плагин Diffblue Cover через меню IntelliJ IDEA, чтобы подогнать его под свои нужды.
Если вам хочется поэкспериментировать, рекомендую начать с базового проекта. Ниже приведен пример проекта Spring Boot с контроллером, уровнем обслуживания, репозиторием, использующим данные spring, и резидентной (In-Memory)базой данных:
git clone https://github.com/rhamedy/sample-rest-service.git
Можете спокойно клонировать репозиторий и делать с ним, что угодно.
Шаг 2. Краткое руководство по проекту
Если вы клонировали проект-пример, приведенный выше, то этот раздел для вас. Здесь я кратко покажу классы, для которых мы собираемся создавать юнит-тесты.
Слой контроллера
Вот как выглядит контроллер Spring Boot, который мы собираемся протестировать:
Как показано выше, у нас есть несколько конечных точек для получения списка всех студентов, а также добавления, получения и удаления по идентификатору каждого в отдельности.
Сервисный слой
Слой сервиса соединяет контроллер со слоем репозитория, где будет находиться большая часть логики.
Дальше мы попытаемся сгенерировать модульные тесты для вышеперечисленных классов с помощью плагина Diffblue Cover.
Шаг 3. Генерация юнит-тестов при помощи плагина, основанного на искусственном интеллекте
Именно здесь происходит вся магия. Другими словами, плагин, работающий на основе ИИ, вступает в дело и самостоятельно, без какой-либо помощи, генерирует юнит-тесты.
Если вы уже установили плагин, щелкните правой кнопкой мыши по StudentController и выберите опцию “Написать тесты” (Write Tests) в меню действий, как показано выше.
Плагин начнет анализировать контроллер и каждый из его методов. Наконец, он сгенерирует юнит-тесты для каждого из методов.
Генерация тестов занимает какое-то время — Diffblue Cover анализирует класс и его методы. Но затраты времени минимальны по сравнению с тем, сколько понадобится для написания вручную.
Ниже приведен тест StudentControllerTest, сгенерированный Diffblue Cover.
Тесты выглядят очень надежными и следуют лучшим практикам Spring Boot относительно тестирования.
Все сгенерированные юнит-тесты целиком можно найти в этом пулл-реквесте.
Шаг 4. Тестовое покрытие сгенерированных юнит-тестов
Инструмент покрытия кода или тестового покрытия показывает процент кода, охваченного тестами.
Запустим его на сгенерированных ранее тестах, чтобы получить представление о том, какой процент кода покрывается этими тестами.
Мы получили довольно хороший процент покрытия по классам, для которых были сгенерированы тесты, то есть по пакетам Controller, service и util.
Стоит отметить, что это крайне простая кодовая база без сложного кода или логики, и плагин, похоже, прилично справляется с работой по созданию ряда надежных модульных тестов. В случае устаревшего кода или запутанной базы плагин может вести себя по-другому.
Демонстрация по созданию юнит-тестов с плагином Diffblue Cover
Для тех, кому интересно, я приготовил также быструю видео-демонстрацию процесса: начиная от установки плагина до генерации тестов и оценки покрытия для сгенерированных тестов.
Быстрое демо по генерации как юнит-тестов на Java с помощью Diffblue Cover
Недостатки автоматизированной генерации юнит-тестов
Несмотря на многие преимущества, которые дает генерация юнит-тестов, у нее есть несколько недостатков, которые я хотел бы вкратце затронуть.
Во-первых, я полагаю, что разработчик, который пишет юнит-тесты, лучше, чем разработчик, который этого не делает.
Во-вторых, на мой взгляд, юнит-тестирование косвенно влияет на то, как мы пишем код. Если мы пишем код, который плохо спроектирован, то модульное тестирование становится еще более неприятным процессом. К примеру, представим метод, который делает десять разных вещей, и к тому же в нем содержится много вложенных условий и довольно сложная логика. Было бы непросто написать тесты, которые охватывают все пути выполнения таких методов.
Однажды, когда я приводил аргументы в пользу юнит-тестирования, один разработчик сказал мне:
Я трачу 20% своего времени на написание кода и 80% на написание юнит-тестов для этого кода.
Если код, который вы пишете, нелегко читать и понимать, он сильно связан и мало сопряжен, то модульное тестирование окажется очень трудоемким и неэффективным процессом.
Заключение
В целом я остался доволен работой плагина и качеством сгенерированных юнит-тестов для проекта-образца.
Однако я заметил, что плагин не может генерировать тесты для определенных классов и в некоторых случаях пропускает пути выполнения (ветви). В видео-примере выше есть дополнительная информация на этот счет.
Читайте также:
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Rafiullah Hamedy: Use an AI Tool to Write Your Unit Tests
