Как организован процесс написания и ревью автотестов в команде

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

Как вы относитесь к тестам: как к части задачи или как к повинности после кода. Интервьюер хочет услышать реальный процесс из вашей практики, а не пересказ учебника. Следом часто спрашивают, что вы делаете с нестабильным тестом.

Как отвечать

Опишите процесс, в котором работали, по шагам и со своими деталями:

• кто пишет: в Java-командах модульные и интеграционные тесты обычно пишет автор фичи в том же merge request. Задача без тестов не готова, это прописано в Definition of Done;
• стек: JUnit 5, AssertJ для читаемых проверок, Mockito для заглушек, Testcontainers с настоящим PostgreSQL или Kafka вместо H2, @SpringBootTest и срезы вроде @WebMvcTest и @DataJpaTest;
• соглашения: имя теста описывает поведение, структура given/when/then, один сценарий на тест, данные через билдеры;
• CI как первый ревьюер: тесты гоняются на каждый merge request, JaCoCo считает покрытие, SonarQube проверяет quality gate на новом коде. Красный пайплайн не мержится;
• ревью человеком: проверяют, что тест падает при поломке логики, покрывает граничные случаи и не завязан на детали реализации. Полезный вопрос ревьюера: «что сломается, если убрать эту строку?»;
• нестабильные тесты: заводятся задачей и чинятся в приоритете, а не перезапускаются до зелёного.

Если тестов в команде почти не было, скажите честно и расскажите, что сделали сами: покрыли баг тестом перед исправлением, внедрили Testcontainers, предложили правило для MR. Это ценится больше идеальной картинки. И задайте этот вопрос работодателю: ответ многое говорит о зрелости команды.

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

Называют своим процессом TDD, но не могут описать ни одного цикла red, green, refactor. Лучше честно сказать, что пишете тесты вместе с кодом.

Делают покрытие целью. Оно показывает, какой код выполнялся, а не что он проверен.

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