Какие виды тестов существуют

Что проверяют

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

Как отвечать

Сначала разведите оси, иначе список превращается в кашу:

• по уровню: юнит, интеграционные, системные (end-to-end);
• по цели: функциональные и нефункциональные (производительность, безопасность, надёжность);
• по поводу запуска: смоук, регрессия, приёмочные. Регрессия это не отдельный вид, а повторный прогон существующих тестов.

Потом пройдитесь по уровням со стеком:

• юнит: JUnit Jupiter, AssertJ для проверок, Mockito для заглушек. Один класс без Spring-контекста, миллисекунды на тест;
• срезы Spring Boot: @WebMvcTest поднимает только веб-слой, @DataJpaTest только JPA, это быстрее полного контекста;
• интеграционные: @SpringBootTest с настоящей базой в Testcontainers вместо H2, потому что H2 ведёт себя не как PostgreSQL;
• контрактные: Spring Cloud Contract или Pact, проверяют, что сервис и клиенты одинаково понимают API;
• end-to-end и UI: Selenium или Playwright для Java, их мало, они медленные и хрупкие;
• производительность: Gatling или JMeter для сервиса, JMH для микробенчмарка метода.

Плюсом будут мутационное тестирование через PIT, которое проверяет, ловят ли тесты изменения в коде, и ArchUnit для правил архитектуры.

Упомяните сборку: в Maven плагин Surefire гоняет юнит-тесты на фазе test, а Failsafe гоняет интеграционные (*IT) на фазе integration-test, чтобы медленные тесты не тормозили каждую сборку.

Где спотыкаются

Называют тест с @SpringBootTest юнит-тестом. Если стартует контекст и база, это интеграционный тест, даже если проверка в нём одна.

Гоняют интеграционные тесты на H2 и получают зелёную сборку, которая падает на реальном PostgreSQL.

Меряют качество процентом покрытия. Строки можно покрыть без единой проверки, покрытие показывает только то, что точно не проверено.