Backend-тесты не только на status 200
На review ты видишь тест, который проверяет только HTTP 200. Что с ним не так и как сделать проверку полезной?
Короткий ответ
Status 200 проверяет только оболочку. Полезный тест должен проверять бизнес-эффект: запись в БД, вызов зависимости, side effects, ошибки, права и важные edge cases.
Полный разбор
Тест "endpoint вернул 200" часто почти ничего не доказывает. Нужно понять контракт фичи: что должно измениться в системе и какие инварианты должны сохраниться. Для create/update endpoint это может быть запись в БД, корректные поля, транзакционность, публикация события, idempotency и обработка невалидного input.
В backend обычно нужна пирамида: unit-тесты для чистой логики, integration-тесты с БД/очередью для важных сценариев, contract-тесты для внешних API и producer/consumer схем. Регресс должен ловиться до ручной передачи QA.
На review стоит просить тесты, которые падают при реальной поломке бизнес-сценария, а не просто выполняют happy path без assert-ов.
Теория
Хороший тест проверяет observable behavior и инварианты, а не факт вызова endpoint-а.
Типичные ошибки
- Проверять только status code.
- Не проверять состояние базы и side effects.
- Игнорировать negative cases и permissions.
Как отвечать на собеседовании
- Приведи пример: не только 200, но и созданный объект в БД.
- Упомяни unit/integration/contract уровни.