Всем привет! Это вопрос мы задаем себе каждый раз, когда надо и не хочется писать тесты. И еще меньше хочется искать и исправлять ошибки в том, что нагенерит AI-ассистент. В этой статье обсудим, на какие инструменты стоит обратить внимание, каким должен быть хороший инструмент для генерации Java тестов и насколько далека мечта от реальности.

На кого будем смотреть?

Как Java программистам, нам нужен:

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

AI инструментов в маркетплейсе сейчас тысячи, и 4. критерием срезаются они почти все.
Из достаточно проработанных открытых инструментов имеет смысл смотреть на Continue и CodeGPT, однако они в первую очередь ориентированы на VSCode и с поддержкой IDEA всё довольно туго: регулярно их переустанавливаю и пробую снова, но они в основном выдают случайные ошибки. Continue.dev ещё и вешает IDEA намертво – такого нам не надо. Ничего магического они не делают, просто переадресуют то, что вы пишите в чате, на провайдеров, так что вместо них возьмём просто ChatGPT-4o (каждый из нас хоть раз пробовал копипастить код из IDE в chatgpt.com, так что такое сравнение будет полезно).

Из удовлетворяющих критерию 4. остаются следующие инструменты:

1. ChatGPT-4o: ручное копирование в chatgpt.com, как мы описали выше.
2. JetBrains AI Assistant: ассистент от JetBrains, сделанный специально под IDEA – должен быть лучшим в плане интеграции с IDE и рабочими процессами Java разработчика.
3. GigaCode: ассистент от команды Сбера, который можно использовать не только с GigaIDE, но и с любыми IDEA-совместимыми средами.
4. Qodo: специализированный ассистент для генерации тестов.
5. Explyt Test: наш плагин, специализированный на написании и поддержке тестов для Java и Kotlin. Фишки AI ассистента в нём тоже есть.

Качество генерируемых тестов

На чём меряем?

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

Мы взяли перечисленные выше инструменты и прогнали их тестогенерацию на нашем внутреннем бенчмарке. Бенчмарк состоит из 27 Java, Kotlin, Spring проектов с JUnit 4, JUnit 5, TestNG, Mockito, Mockk — в общем, с разными возможными конфигурациями проектов и используемых фреймворков в коде и в тестах.

В нашем бенчмарке имеются как открытые проекты с GitHub, так и закрытые проекты дружественных Enterprise компаний, над которыми работают более тысячи Java разработчиков. В каждом проекте были выбраны классы, на которые пишут разные виды тестов: например, контроллеры, сервисы, util классы и так далее.

Что меряем?

В каждом из указанных инструментов тем или иным путём можно по классу сгенерировать тестовый класс. Далее мы измеряем следующие метрики у сгенерированного тестового класса.

Первая метрика — компилируемость. Почему это хорошая метрика?

Во-первых, она коррелирует с качеством используемой модели: например, GPT-3.5 в среднем генерировала менее компилируемый код, чем GPT-4 (на тех же промптах).

Во-вторых, она коррелирует с качеством используемого промпта. Вы удивитесь, но даже в 2025 году и даже с большими SOTA моделями есть разница, какой у вас промпт: "Write tests please" или один экран текста с деталями того, что именно хочется.

В-третьих, эта метрика коррелирует с тем, как плагин работает с вашей кодовой базой, а именно: как собирает релевантный контекст кода. Наши классы не живут сами по себе: они зависят друг от друга, передаются друг другу в качестве параметров и т.п. Если вы тестируете метод, принимающий интерфейс, то у вас должна быть возможность получить тесты с разными перегрузками этого интерфейса. Хороший плагин должен аккуратно собирать релевантный контекст для генерации хороших тестов. Это ещё более важно в контексте Spring, ведь благодаря dependency injection добавляются неявные зависимости по коду. Если плагин собирает слишком мало контекста вашего кода, LLM будет галлюцинировать и код тестов не будет компилироваться. Если плагин соберёт лишний контекст, даже умная большая модель будет путаться.

Вторая метрика — тестовое покрытие. Она, конечно, не гарантирует, что тесты хорошие, однако работает в обратную сторону: если какой-то код не покрыт тестами, скорее всего там есть баг. Таким образом, мы ожидаем от плагина генерации тестов хорошего покрытия.

Результаты сравнения

В полученных результатах есть несколько нюансов.

Во-первых, напомним, что означает ChatGPT-4o**. Это не плагин, а имитация отсутствия плагина, по сути аналог простых плагинов, вроде CodeGPT или Continue.dev: мы вручную копируем тестируемый класс и просим сгенерировать для него тесты на chatgpt.com (с GPT-4o).

Во-вторых, * — это проценты с учётом сделанных ручных исправлений (добавления импортов). Инструменты с этой меткой либо не импортировали нужные классы, либо импортировали не все, из-за чего ошибок компиляции было очень много. Поэтому мы вручную вставили нужные импорты и только потом провели замеры. Спасибо IDEA, большинство импортов добавляются легко через Alt-Enter, но для некоторых это не так: приходилось думать. Это говорит не в пользу указанные инструментов. Фактически для всех отмеченных звёздочкой * инструментов без ручной правки кода не компилировался ни один сгенерированный тестовый класс.

В-третьих, у инструментов иногда возникали случайные проблемы. Например, JetBrains AI assistant и GigaCode в 7% запусков обрывали генерацию теста на середине, поэтому её приходилось перезапускать.

Qodo в 4% генераций вместо одного тестового класса с несколькими тестовыми методами генерировал по одному тестовому классу с одним тестовым методом на каждый кейс. GigaCode в 3% генераций вставлял заглушки вместо кода тестовых методов, т.е. код вида:

@Test
fun test() {
  // Write code yourself
}

Что инструменты сгенерировали?

Здесь вы можете увидеть результаты генерации для сравниваемых инструментов. Мы оставили только по 2 тестовых метода в каждом классе, так как все остальные методы устроены аналогично.

package com.commerce.backend.api;

import com.commerce.backend.model.request.order.PostOrderRequest;
import com.commerce.backend.model.response.order.OrderResponse;
import com.commerce.backend.service.OrderService;
import org.junit.jupiter.api.Test;
import org.mockito.Mockito;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.mock.mockito.MockBean;
import org.springframework.http.MediaType;
import org.springframework.test.web.servlet.MockMvc;

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.post;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.jsonPath;
import static org.hamcrest.Matchers.is;

@SpringBootTest
@AutoConfigureMockMvc
public class OrderControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @MockBean
    private OrderService orderService;

    @Test
    public void postOrder_withInvalidShipName_shouldReturnBadRequest() throws Exception {
        mockMvc.perform(post("/order")
                        .contentType(MediaType.APPLICATION_JSON)
                        .content("""
                                {
                                    "shipName": "",
                                    "shipAddress": "123 Main St",
                                    "billingAddress": "123 Main St",
                                    "city": "Springfield",
                                    "state": "Illinois",
                                    "zip": "62704",
                                    "country": "USA",
                                    "phone": "12345678901"
                                }
                                """))
                .andExpect(status().isBadRequest())
                .andExpect(jsonPath("$.shipName", is("must not be blank")));
    }

    @Test
    public void postOrder_withMissingFields_shouldReturnBadRequest() throws Exception {
        mockMvc.perform(post("/order")
                        .contentType(MediaType.APPLICATION_JSON)
                        .content("""
                                {
                                    "shipName": "",
                                    "shipAddress": "",
                                    "billingAddress": "",
                                    "city": "",
                                    "state": "",
                                    "zip": "",
                                    "country": "",
                                    "phone": ""
                                }
                                """))
                .andExpect(status().isBadRequest());
    }
}

Как видно, JetBrains AI Assistant посылает запросы в виде строк с JSON'ами, а не строит Java объекты с использованием ObjectMapper'а.

package com.commerce.backend.api;
// Generated by Qodo Gen

import com.commerce.backend.api.OrderController;
import com.commerce.backend.error.exception.InvalidArgumentException;
import com.commerce.backend.service.OrderService;
import org.junit.Test;
import org.mockito.Mockito;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;

import static org.junit.Assert.*;

public class OrderControllerTest {

    // getAllOrdersCount returns order count with HTTP 200 status
    @Test
    public void test_get_all_orders_count_returns_count_with_ok_status() {
        // Arrange
        OrderService orderService = Mockito.mock(OrderService.class);
        OrderController orderController = new OrderController(orderService);
        Integer expectedCount = 5;
        Mockito.when(orderService.getAllOrdersCount()).thenReturn(expectedCount);

        // Act
        ResponseEntity<Integer> response = orderController.getAllOrdersCount();

        // Assert
        assertEquals(HttpStatus.OK, response.getStatusCode());
        assertEquals(expectedCount, response.getBody());
        Mockito.verify(orderService).getAllOrdersCount();
    }

    // getAllOrders with negative page value throws InvalidArgumentException
    @Test
    public void test_get_all_orders_with_negative_page_throws_exception() {
        // Arrange
        OrderService orderService = Mockito.mock(OrderService.class);
        OrderController orderController = new OrderController(orderService);
        Integer negativePage = -1;
        Integer validPageSize = 10;

        // Act & Assert
        InvalidArgumentException exception = assertThrows(
                InvalidArgumentException.class,
                () -> orderController.getAllOrders(negativePage, validPageSize)
        );

        assertEquals("Invalid page", exception.getMessage());
        Mockito.verify(orderService, Mockito.never()).getAllOrders(Mockito.anyInt(), Mockito.anyInt());
    }
}

Qodo всю логику написал внутри тестовых методов, из-за чего дублируются моки OrderService. Кроме того, Qodo написал для контроллера юнит тест, а не интеграционный.

package com.commerce.backend.api;

import com.commerce.backend.error.exception.InvalidArgumentException;
import com.commerce.backend.model.request.order.PostOrderRequest;
import com.commerce.backend.model.response.order.OrderResponse;
import com.commerce.backend.service.OrderService;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;

import java.util.Arrays;
import java.util.List;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;
import static org.mockito.Mockito.*;

@ExtendWith(MockitoExtension.class)
public class OrderControllerTest {

    @Mock
    private OrderService orderService;

    @InjectMocks
    private OrderController orderController;

    private PostOrderRequest postOrderRequest;
    private OrderResponse orderResponse;

    @BeforeEach
    public void setUp() {
        postOrderRequest = new PostOrderRequest();
        orderResponse = new OrderResponse();
    }

    @Test
    public void testGetAllOrders() {
        List<OrderResponse> orders = Arrays.asList(orderResponse);
        when(orderService.getAllOrders(0, 10)).thenReturn(orders);

        ResponseEntity<List<OrderResponse>> response = orderController.getAllOrders(0, 10);

        assertEquals(HttpStatus.OK, response.getStatusCode());
        assertEquals(orders, response.getBody());
        verify(orderService, times(1)).getAllOrders(0, 10);
    }

    @Test
    public void testGetAllOrdersWithInvalidPage() {
        assertThrows(InvalidArgumentException.class, () -> orderController.getAllOrders(-1, 10));
    }
}

GigaCode также для контроллера сгенерировал юнит тест, а не интеграционный. В отличие от Qodo, общие сущности он вынес в поля и setUp метод.

package com.commerce.backend.api;

import org.junit.jupiter.api.Test;
import org.mockito.MockBean;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest;
import org.springframework.http.MediaType;
import org.springframework.test.web.servlet.MockMvc;
import org.springframework.test.web.servlet.request.MockMvcRequestBuilders;
import org.springframework.test.web.servlet.result.MockMvcResultMatchers;
import com.commerce.backend.api.OrderController;
import com.commerce.backend.service.OrderService;
import com.commerce.backend.model.response.OrderResponse;
import com.commerce.backend.model.request.PostOrderRequest;
import java.util.ArrayList;
import java.util.List;
import static org.mockito.Mockito.when;

@WebMvcTest(OrderController.class)
public class OrderControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @MockBean
    private OrderService orderService;

    @Test
    public void testGetAllOrdersCount() throws Exception {
        when(orderService.getAllOrdersCount()).thenReturn(5);

        mockMvc.perform(MockMvcRequestBuilders.get("/order/count"))
                .andExpect(MockMvcResultMatchers.status().isOk())
                .andExpect(MockMvcResultMatchers.content().string("5"));
    }

    @Test
    public void testPostOrder_ValidRequest() throws Exception {
        PostOrderRequest postOrderRequest = new PostOrderRequest(/* parameters */);
        OrderResponse orderResponse = new OrderResponse(/* parameters */);
        when(orderService.postOrder(postOrderRequest)).thenReturn(orderResponse);

        mockMvc.perform(MockMvcRequestBuilders.post("/order")
                .contentType(MediaType.APPLICATION_JSON)
                .content(/* JSON representation of postOrderRequest */))
                .andExpect(MockMvcResultMatchers.status().isOk())
                .andExpect(MockMvcResultMatchers.jsonPath("$.id").value(orderResponse.getId()));
    }
}

ChatGPT-4o сгенерировал интеграционные тесты, однако поленился и вставил заглушки вместо кода: /* JSON representation of postOrderRequest */ и /* parameters */. Этот код, конечно, не скомпирилуется.

package com.commerce.backend.api;

import com.commerce.backend.model.request.order.PostOrderRequest;
import com.commerce.backend.model.response.order.OrderResponse;
import com.commerce.backend.service.OrderService;
import com.fasterxml.jackson.databind.ObjectMapper;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest;
import org.springframework.boot.test.mock.mockito.MockBean;
import org.springframework.http.MediaType;
import org.springframework.test.web.servlet.MockMvc;
import org.springframework.test.web.servlet.request.MockMvcRequestBuilders;
import org.springframework.test.web.servlet.result.MockMvcResultMatchers;

import java.util.Collections;
import java.util.List;

import static org.mockito.Mockito.when;

@WebMvcTest(OrderController.class)
public class OrderControllerTest {

    //region Generated with Explyt. Tests for OrderController

    @Autowired
    private MockMvc mockMvc;

    @MockBean
    private OrderService orderService;

    /**
     * Given there are multiple orders in the system<br>
     * And an invalid page size is specified (e.g., negative number)<br>
     * When a request is made to retrieve the orders with the invalid page size<br>
     * Then the system should throw an "Invalid pageSize" error
     */
    @Test
    public void testGetAllOrdersWithInvalidPageSize() throws Exception {
        Integer page = 0;
        Integer invalidPageSize = -1;

        mockMvc.perform(MockMvcRequestBuilders.get("/order")
                        .param("page", String.valueOf(page))
                        .param("size", String.valueOf(invalidPageSize)))
                .andExpect(MockMvcResultMatchers.status().isBadRequest())
                .andExpect(MockMvcResultMatchers.content().string("Invalid pageSize"));
    }

    /**
     * Given a valid order request with all necessary shipping and billing details<br>
     * When a request is made to create a new order<br>
     * Then the system should successfully create the order<br>
     * And return the order details in the response
     */
    @Test
    public void testPostOrderWithValidDetails() throws Exception {
        PostOrderRequest postOrderRequest = new PostOrderRequest();
        postOrderRequest.setShipName("John Doe");
        postOrderRequest.setShipAddress("123 Main St");
        postOrderRequest.setBillingAddress("123 Main St");
        postOrderRequest.setCity("Anytown");
        postOrderRequest.setState("State");
        postOrderRequest.setZip("12345");
        postOrderRequest.setCountry("Country");
        postOrderRequest.setPhone("1234567890");

        OrderResponse expectedOrderResponse = new OrderResponse();
        when(orderService.postOrder(postOrderRequest)).thenReturn(expectedOrderResponse);

        mockMvc.perform(MockMvcRequestBuilders.post("/order")
                        .contentType(MediaType.APPLICATION_JSON)
                        .content(new ObjectMapper().writeValueAsString(postOrderRequest)))
                .andExpect(MockMvcResultMatchers.status().isOk())
                .andExpect(MockMvcResultMatchers.jsonPath("$.shipName").value("John Doe"));
    }

    //endregion

}

Explyt Test сгенерировал интеграционные тесты для контроллера, не оставил //TODO дырок, входные данные построил Java кодом. Кроме того, плагин добавил комментарии на естественном языке, описывающие, что делает тест.

Что требуется от генерации тестов кроме качества самих тестов?

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

1. Писать код тестов не в своём оторванном от кода чат окне, а в правильном файле с правильным именем в нужном source руте.
2. Код тестов должен соответствовать стилю вашего проекта, принятом в вашей организации.

Какие из указанных плагинов удовлетворяют этим критериям?

1. Ручное копирование в chatgpt.com им не удовлетворяет: вам нужно думать, куда копировать код из чата. Вы можете описать стиль вашего проекта или скопировать существующий тестовый класс как пример, но их нужно, опять же, вручную описывать, вручную искать.
2. JetBrains AI Assistant им также не удовлетворяет. При запросе теста он генерирует дифф с кодом. Если дифф принять, он создаст тестовый класс в той же папке, где ваш класс, т.е., например, в папке src/main/org/example/com/service к вашему классу MyService.java добавится файл MyServiceTest.java.
3. GigaCode им не удовлетворяет, т.к. выдаёт код просто в чате.
4. Qodo частично удовлетворяет этим критериям: он позволяет вручную указать, куда положить тестовый класс и какой тестовый класс использовать в качестве референса стиля.
5. Explyt Test обоим критериям удовлетворяет. Мы постарались снять с вас личную механическую работу, поэтому плагин даст типовое имя тестовому классу, сам определит, куда его положить, а также сам найдёт тестовый класс, который можно использовать в качестве референса стиля. Вы также можете их поменять, если у вас есть специфические требования.

Выглядит это вот так:

Какие есть не связанные с тестами требования?

Разберём самый важный вопрос: куда пойдёт мой код? (убьют ли меня security в моей компании?)
У всех приведённых продуктов по умолчанию ваш код отправляется на внешние сервера, где его могут по-разному использовать (в зависимости от лицензионного соглашения). Как правило, вам не гарантируется ничего: ваш код может храниться, его могут видеть люди, на нём могут обучаться новые модели и т.п. Как говорится, "если что-то бесплатно, значит продукт – это ты".

Продукты могут по-разному дать вам возможность обрести уверенность в том, что происходит с вашим кодом.

1. Плагин может дать возможность использовать модели разных провайдеров со своим API ключом. Тогда вы можете, например, купить подписку от OpenAI, в лицензионном соглашении которой написано, что с вашим кодом делать ничего не будут. Плюсы: вы получаете доступ к передовым моделям, вам не нужна дополнительная подписка (вы уже заплатили провайдеру). Минусы: ваш код всё ещё на чьих-то непонятных серверах, скорее всего не в России.

   
   

2. Плагин может позволять использовать локальную модель (например, через Ollama или LM Studio). Скорее всего вы не захотите это делать, потому как на среднем ноутбуке для разработчика вы сможете запустить разве что ~14B модель на скорости порядка 4 токенов в секунду (если средний тестовый класс на Java 1500 токенов, вам придётся ждать генерации одного теста 1500 / 4 = 375 секунд = 6.25 минут). Лучшая модель примерно такого размера будет давать вам качество как у gpt-3.5-turbo, т.е. генерировать что-то, но после неё надо будет всё исправлять. Если у вас неплохой GPU (например, 4090 или 5090), то вы в лучшем положении, но качество сгенерённых тестов всё ещё будет довольно низким, как и скорость генерации. Плюсы: всё у вас на устройстве. Минусы: медленно и некачественные результаты.

   
   

3. Плагин может дать использовать развёрнутую в контуре вашей компании модель, имея её внутренний IP адрес и личный API ключ, если она развёрнута в виде OpenAI-совместимого провайдера. Вам только нужно узнать по внутренним каналам компании, на каком адресе развёрнута модель и какой нужен API ключ (если вообще нужен). Плюсы: всё в контуре вашей компании. Минусы: обычно плагины затачиваются под конкретные модели, так что качество будет хуже (кроме того, если в вашей компании для экономии развёрнута старая маленькая модель, то результаты будут очень плохие).

   
   

4. У плагина может быть официальная Enterprise версия, позволяющая развернуть его в контуре компании. Плюсы: поддержка разработчиков, вы можете повлиять на то, какие будут новые фичи, плагин специализирован под ту модель, которую у вас развернут. Минусы: ваша компания должна за это заплатить.

   
   

Есть небольшие побочные свойства продукта, которые могут повлиять на то, сможем ли мы его использовать:

1. Можно ли просто початиться с LLM?
2. Есть ли автодополнение кода?
3. Есть ли поддержка VSCode?
4. Можно ли использовать из России без VPN?
5. Сколько это стоит?

Их рассмотрим далее в сводной таблице.

Итоги

Итак, соединим всё рассмотренное в одну таблицу

* — с доп. правками руками (без них проценты около 0%)
** — будет в ближайшем релизе

Заключение

Мы сравнили специализированные и неспециализированные AI инструменты для генерации тестов. Увидели, что генерация тестов есть в любых AI ассистентах, и её даже можно делать "на коленке", пересылая код в chatgpt.com. Проблема в том, что от неспециализированного инструмента вы скорее всего получите некачественный результат, с которым потом будете долго возиться (и встанет вопрос, не быстрее ли было всё сделать вручную?).

Кроме генерации тестов, в Explyt Test плагине, есть такие специализированные фичи как повышение тестового покрытия и анализ моргающих (flaky) тестов. О том, как они устроены и как помогают программистам в повседневной работе, расскажем в следующих постах. А пока будем рады вашей обратной связи и вопросам в комментариях.

Скачать последнюю версию Explyt Test плагина можно на сайте или напрямую с GitHub.

Для обратной связи и сообщений об ошибках: GitHub Issues

Для общения: t.me/explyttest