Что такое GraphQL с точки зрения тестирования API?

Да ты посмотри, что эти фронтендеры выдумали! GraphQL, блядь. Ну классика — вместо того чтобы нормальные эндпоинты наделать, они запихнули всё в одну дырку под названием /graphql. Ёперный театр, представляешь? Теперь клиентская сторона сама, как в столовой, набирает в тарелку, что хочет: картошечку, котлетку, а компот — не надо. И всё одним подходом!

С точки зрения нас, тестировщиков, это, конечно, и пизда рулю, и головная боль одновременно. Вместо того чтобы бегать по двадцати разным урлам, как угорелый, ты торчишь на одной этой точке. Но расслабляться нельзя, чувак, доверия ебать ноль. Потому что теперь вся логика упёрлась в схему (Schema). Её тестить — святое дело. Там каждый тип данных, каждое обязательное поле (эти твои non-nullable), все связи между сущностями — всё должно быть как швейцарские часы, иначе клиент получит такую ошибку, что сам от себя охуеет.

А тестировать-то чего? Да всё, что умеет эта штука:

• Запросы (Queries) — чтобы данные просто отдавались, как просили.
• Изменения (Mutations) — чтобы можно было что-то создать, обновить или удалить, и всё не накрылось медным тазом.
• Подписки (Subscriptions) — это когда данные должны сами течь, как по трубе, в реальном времени. Тут вообще веселье начинается.

И главное — обработка ошибок. Это святое! В REST если запрос кривой — он целиком и полностью отвалится. А тут, сука, запрос может частично выполниться, а частично — плюнуть тебе в лицо ошибкой. Надо проверять, что система в такой ситуации не обосрётся, а красиво и понятно скажет, что пошло не так.

Вот, смотри, как примерно это выглядит в коде. Простой тест на pytest с requests:

import pytest
import requests

GRAPHQL_ENDPOINT = "https://api.example.com/graphql"

def test_graphql_query_returns_requested_fields_only():
    """Проверяем, что ответ содержит только запрошенные поля."""
    query = """
    query {
      project(id: "123") {
        name
        status
        # Поле 'description' намеренно не запрашиваем
      }
    }
    """

    response = requests.post(GRAPHQL_ENDPOINT, json={'query': query})
    data = response.json()

    assert response.status_code == 200
    assert 'errors' not in data

    project_data = data['data']['project']
    # Проверяем наличие ожидаемых полей
    assert 'name' in project_data
    assert 'status' in project_data
    # Убеждаемся, что лишние поля не "просочились"
    assert 'description' not in project_data

Суть теста в чём? Мы просим только name и status. И мы должны быть на 146% уверены, что нам в ответ не прилетит ещё и description, или там createdAt, или какая-нибудь манда с ушами. Это принципиально! Иначе зачем весь этот цирк с GraphQL?

Так на чём же забить, простите, зафокусировать свой взор тестировщику?

1. Валидация схемы — это фундамент. Без него всё развалится.
2. Тестирование резолверов — тех самых функций, которые бегают за данными в базу или ещё куда. Они должны работать быстро и без ошибок.
3. Производительность, ёпта! Тут главная страшилка — проблема N+1. Клиент одним запросом может вытащить проект, всех его юзеров, а у каждого юзера — все его задачи. И если резолверы написаны криво, сервер сойдёт с ума, делая овердохуища запросов в базу. Надо ловить такие моменты.
4. Безопасность. Надо запрещать слишком сложные, вложенные запросы, которые могут загрузить сервер так, что он будет лежать и блевать. Иначе какой-нибудь пидарас шерстяной специально таким запросом положит тебе продакшен.

В общем, инструмент мощный, но и ответственности с ним — как с атомным реактором. Подходи с умом, а то будет вам не Хиросима, а Нагасаки.