Что и где тестировать в клиент-серверной архитектуре

Что и где тестировать в клиент-серверной архитектуре

Введение

Понимание архитектуры приложения — это суперсила тестировщика. Когда ты знаешь, как данные путешествуют от пользователя до базы данных и обратно, ты можешь строить осмысленные тест-кейсы, а не просто «тыкать кнопки». В этом уроке — комплексная стратегия тестирования клиент-серверных приложений.

Архитектура, которую мы тестируем

Пользователь → Браузер (Frontend) → HTTP → Backend API → БД
                                              ↕
                                        Внешние сервисы
                                    (платёжный шлюз, email и т. д.)

Frontend-проверки (UI-уровень)

Отображение данных

• Данные из API корректно отображаются (числа как числа, даты в нужном формате).
• Длинный текст не ломает вёрстку.
• Пустые значения показывают заглушку, а не null или undefined.

Состояния загрузки

• Спиннер появляется во время ожидания ответа API.
• При медленном соединении страница не «зависает» молча.

Валидация форм

• Обязательные поля подсвечиваются при попытке отправить пустыми.
• Неправильный email/телефон показывает понятное сообщение.
• Кнопка Submit блокируется при невалидных данных.

Отображение ошибок

• При ошибке API (4xx, 5xx) пользователь видит понятное сообщение, а не белый экран.
• Сообщение об ошибке соответствует ситуации (не «что-то пошло не так» везде).

API-проверки (Backend-уровень)

Коды ответов

• Успешные операции → правильные 2xx (200, 201, 204).
• Ресурс не найден → 404, а не 200 с пустым телом.
• Неверные данные → 400 или 422 с описанием ошибки.

Схема ответа

• Все ожидаемые поля присутствуют.
• Типы данных соответствуют контракту.
• Нет лишних/чувствительных полей (пароли, внутренние ключи).

Обработка ошибок

• 4xx-ответы содержат понятное сообщение об ошибке в теле.
• Сообщение об ошибке не раскрывает внутренние детали (стек trace, имена таблиц).

Граничные случаи

• Запрос с пустым телом.
• Запрос с отсутствующими обязательными полями.
• Очень длинные строки.
• Специальные символы в строках.
• Числа-экстремумы (0, -1, MAX_INT).

Интеграционные проверки

Проверяем, что слои правильно «разговаривают» друг с другом:

Проверки базы данных

• Данные сохранились: после POST через API → найди запись в БД.
• Данные удалились: после DELETE → записи нет в БД (или помечена как deleted, если soft delete).
• Ограничения работают: попробуй создать дубликат — БД вернёт ошибку, API — 409.
• Транзакции: при ошибке посередине — частично созданные данные не остаются.

Security-проверки

Производительность: ориентиры для тестировщика

Частые ошибки тестировщиков

• Тестировать только happy path. Большинство багов прячется в граничных случаях и ошибках.
• Не проверять интеграцию слоёв. API может работать правильно, а UI отображать неправильно.
• Игнорировать пустые состояния. Что показывается, если данных нет? Пустой список или ошибка?
• Не проверять сообщения об ошибках. «Ошибка 500» — плохое UX. «Не удалось сохранить. Попробуй ещё раз» — хорошее.

Что мы запомним

• Тестируй все уровни: UI (отображение, формы, ошибки), API (коды, схема, edge cases), БД (персистентность).
• Интеграционные тесты проверяют, что слои корректно взаимодействуют.
• Security: всегда проверяй авторизацию, ролевой доступ и IDOR.
• Ориентиры производительности: API < 200 мс, страница < 1 сек.
• Пустые состояния, граничные значения и ошибки — обязательная часть тест-плана.