В чем разница между комплексным тестированием приложения и тестированием API?

А, ну вот, опять про тесты заговорили. Давай разберёмся, чтобы не путать хуй с пальцем, а то некоторые думают, что это одно и то же.

Смотри, тестирование приложения — это как проверить всю тачку целиком: заводится ли, едет ли, фары горят, кондей дует, магнитола орет, не отваливаются ли колеса на ходу. То есть полный аудит, от мелкой гайки до того, как она в целом по дороге катится.

А тестирование API — это, блядь, как залезть под капот и ткнуть мультиметром в конкретные провода на разъёме «мозгов». Проверить, приходит ли на контакт «А12» нужные 5 вольт, когда ты жмешь кнопку «открыть окно». Это часть общей проверки, но очень узкая и техническая.

Тестирование приложения (Application Testing) — это овердохуища разных проверок:

• Юнит-тесты: Отдельно потрогать каждый винтик. Работает ли функция calculatePrice() сама по себе, если ей скормить три рубля и два яблока.
• Интеграционные тесты: Собрать эти винтики в узлы. А вот если этот модуль «корзины» поговорит с модулем «склада», они друг друга правильно поймут? Тестирование API — это как раз один из главных видов таких интеграционных проверок, ёпта!
• End-to-End (E2E) тесты: Сесть за руль и проехать от точки А до Б. Полный сценарий: «зарегался -> залогинился -> нашел товар -> кинул в корзину -> купил». И всё это через интерфейс, который видит юзер.
• UI-тесты: А кнопки-то нажимаются? А шрифт не съехал? А этот выпадающий список вообще выпадает, или он просто для красоты нарисован?
• Нагрузочные тесты: А что будет, если не ты один, а десять тысяч таких же умников одновременно начнут жать кнопку «купить»? Не ляжет ли всё к херам?

Тестирование API (API Testing) — это когда тебе похуй на кнопки и шрифты. Ты бьешь напрямую по заднице приложения, по его программным интерфейсам. Обычно через HTTP.

• Суть: Убедиться, что этот чертов контракт (спецификация) выполняется. Обещал отдать данные по юзеру — отдавай, сука.
• Что смотрим:
  • Присылает ли он правильные HTTP-статусы. 200 — ок, 404 — не найдено, 500 — сервер обосрался. Если просишь несуществующего юзера, а он тебе 200 и улыбку — это пиздец.
  • Тело ответа. JSON должен быть как в документации, а не какая-то левая хуйня с лишними полями или, что хуже, без обязательных.
  • Заголовки. Иногда там должна быть какая-нибудь важная хрень.
  • Скорость. Не должен думать как тугодум.
  • Обработка кривых данных. А что если я ему вместо цифры ID пришлю строку "абвгд"? Он должен вежливо послать меня нахуй с ошибкой 400, а не сдохнуть с 500-ой.

Вот, смотри, как примерно выглядит этот подкапотный укол в Go:

// Этот код не про всю тачку, он тыкает в одну конкретную лампочку — ручку /users/1
func TestGetUserAPI(t *testing.T) {
    req, _ := http.NewRequest("GET", "/users/1", nil)
    rr := httptest.NewRecorder()
    // GetUserHandler — это наш обработчик, та самая железяка под капотом
    handler := http.HandlerFunc(GetUserHandler)
    handler.ServeHTTP(rr, req)

    // Первым делом — статус. Ок ли?
    if status := rr.Code; status != http.StatusOK {
        t.Errorf("handler returned wrong status code: got %v want %v", status, http.StatusOK)
    }

    // А теперь — что внутри? То ли отдал?
    expected := `{"id":1,"name":"John"}`
    if rr.Body.String() != expected {
        t.Errorf("handler returned unexpected body: got %v want %v", rr.Body.String(), expected)
    }
}

Короче, итог, чтобы в голове отложилось: Тестирование API — это проверка контракта твоего бэкенда. Мол, чувак, ты обещал по такому-то адресу отдавать такие-то данные — выполняй. А тестирование приложения — это проверка, что вся эта конструкция в сборе реально решает задачу для пользователя, а не просто красиво договаривается сама с собой.