Какой опыт с unit тестированием

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

Понимаете ли вы место unit-тестов в пирамиде и чем они отличаются от ваших автотестов. Для тестировщика это ещё вопрос о границах роли: пишете ли вы unit-тесты сами или проверяете, что покрыли разработчики. Следом часто спрашивают, как вы договариваетесь, что проверять на каком уровне.

Как отвечать

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

• определение: проверяется одна единица кода в изоляции, без сети, базы и файловой системы, за миллисекунды;
• инструменты: JUnit 5 и Mockito для Java, pytest с unittest.mock или pytest-mock для Python, Jest или Vitest для JavaScript;
• структура: Arrange, Act, Assert, одна причина падения на тест, параметризация через @ParameterizedTest или @pytest.mark.parametrize вместо копипасты;
• тест-дизайн: граничные значения и классы эквивалентности, это ваша сильная сторона, и на unit-уровне она особенно полезна;
• качество тестов: покрытие через JaCoCo или coverage.py показывает непокрытое, но не проверяет силу проверок. Для этого есть мутационное тестирование: PIT, mutmut.

Покажите, как это экономит работу QA: если граница уже проверена в unit-тесте, в UI-регрессе хватит одного позитивного сценария.

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

Называют unit-тестами UI-автотесты на Selenium или Playwright. Это другой уровень пирамиды с другой скоростью и стоимостью.

Ставят целью 80% покрытия. Метрику легко набрать тестами без проверок, и интервьюер обычно спрашивает, как вы отличаете полезное покрытие от формального.

Пишут тесты, которые зависят от порядка запуска или общих данных. По отдельности прогон зелёный, в CI вперемешку красный.