Писали ли автотесты на API на Java и использовали ли экстремальные техники
Что проверяют
Пишете ли вы API-тесты кодом на Java или только кликаете в графическом клиенте, и умеете ли проверять не только счастливый путь. Формулировка про экстремальные техники размытая, и первая проверка тут на то, уточните ли вы её вместо того, чтобы угадывать.
Как отвечать
Сначала переспросите, что имеется в виду: проверки на экстремальных значениях или командные практики вроде разработки через тесты. Дальше отвечайте по делу.
Про инструменты: RestAssured поверх JUnit 5 или TestNG, тела запросов через объекты, а не склейкой строк, WireMock для заглушек соседних сервисов, Testcontainers для базы и брокера рядом с тестом, отчёты в Allure.
Про тест-дизайн скажите, что именно проверяете:
- код ответа, тело, заголовки и схему ответа, а не одно поле;
- негативные случаи: без токена, с чужим токеном, с просроченным токеном, с чужим идентификатором в пути;
- границы и экстремальные значения: пустая строка, максимальная длина и на символ больше, ноль и отрицательное число, юникод и эмодзи, глубокая вложенность, длинные списки;
- поведение при повторе запроса и при двух параллельных запросах к одному ресурсу.
Хорошо звучит про независимость: тест сам готовит данные и сам их убирает, порядок запуска не важен, окружение задаётся конфигурацией, а не правкой кода.
Где спотыкаются
Проверяют только код ответа. Сервис отвечает успехом с пустым телом или с полем в неверном формате, тест зелёный, дефект спокойно уезжает дальше по конвейеру.
Второе: пересказывают набор модных слов, не отделяя своё от командного. Если разработку через тесты в команде вели не вы, честнее так и сказать, чем поплыть на первом уточняющем вопросе о деталях процесса.
Третье: зашивают в тест готовые данные. Проверка, которая ждёт заранее заведённого пользователя, живёт до первой чистки базы, после чего команда привыкает, что часть набора всегда красная, и перестаёт читать отчёты.