Начинайте со схемы и ожидаемого поведения
Схема описывает доступные типы, поля и аргументы. Перед тестом определите, какая операция должна быть допустима и какой результат соответствует подготовленным данным. Неизвестное поле или некорректная структура выбора относятся к проверке запроса до выполнения. Для такого случая важно не только наличие ошибки, но и отсутствие выполнения полей операции. Отдельно рассматривайте значения переменных и ограничения предметной области: допустимый тип ещё не доказывает, что бизнес-действие разрешено. Возраст, количество или состояние объекта могут иметь дополнительные правила.
Проверяйте data и errors вместе
Поле data содержит результат выполнения, а errors описывает возникшие ошибки. При ошибке отдельного поля ответ может включать частичные данные. Поэтому тест на успешный сценарий должен проверять необходимые значения и ожидаемое отсутствие ошибок, а тест на частичный результат обе части ответа. Наличие null требует понимания схемы и контракта: оно не всегда означает одну и ту же причину. HTTP-статусы также зависят от ситуации и используемого формата ответа. Утверждение, что GraphQL всегда возвращает только 200, слишком грубо для надёжного тестирования.
Разделяйте вход в систему и разрешение на данные
Аутентификация подтверждает личность, но не даёт автоматически доступа к каждому объекту и полю. В собственной тестовой среде полезно заранее создать пользователей с разными правами и вымышленные записи. Проверьте разрешённый результат для владельца и согласованное поведение для пользователя без нужного права. Важно не допустить утечки защищённых сведений ни в данных, ни в лишних деталях ошибки. Форма отказа может различаться по контракту сервиса; существенный критерий состоит в соблюдении правила доступа, а не в конкретной красивой формулировке сообщения.
Для изменений проверяйте состояние, а не только ответ
Мутация может изменить запись, создать объект или запустить другое действие. После неё полезно проверить фактическое состояние и отсутствие незапланированных эффектов. Несколько полей одной мутации не означают автоматически общую транзакцию с откатом всего при любой ошибке. Повтор после сетевого сбоя также требует понимания исхода и правил повторяемости: тайм-аут не доказывает, что действие не произошло. Подготавливайте изолированные тестовые данные и способ очистки, соответствующий среде. Проверки не должны менять чужую рабочую информацию или отправлять реальные сообщения.
Попробуйте на практике
Составьте план тестирования учебного GraphQL API для заметок на бумаге или в разрешённой изолированной среде.
- Опишите вымышленные заметки и два тестовых пользователя, явно задав, кто имеет право читать каждую запись.
- Сформулируйте успешный запрос и перечислите ожидаемые поля и значения ответа.
- Добавьте запрос неизвестного поля и определите ожидаемый отказ до выполнения.
- Предусмотрите частичную ошибку чтения и проверку отсутствия доступа у пользователя без права.
- Для учебной мутации запишите проверку состояния после действия и порядок выяснения исхода при сетевом сбое без слепого повтора.
Как проверить результат. План проверяет контракт, обе части ответа, доступ и фактические изменения. Один код HTTP не считается достаточным доказательством успеха, а все данные и действия остаются учебными.
Частые вопросы
Если есть errors, data всегда отсутствует?
Нет. При ошибках выполнения отдельных полей возможны частичные данные. Ошибки запроса до выполнения и ошибки полей нужно рассматривать отдельно.
Проверка схемы заменяет проверку бизнес-правил?
Нет. Корректная форма операции не гарантирует разрешения действия, правильности расчёта или соблюдения ограничений предметной области. Эти условия тестируют дополнительно.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.