Хабрахабр

Что такое API

Содержание

Слово «API» мелькает в вакансиях даже для начинающих тестировщиков. То REST API, то SOAP API, то просто API. Что же это за зверь такой? Давайте разбираться!

Я вообще-то web тестирую! — А зачем это мне? Вот если пойду в автоматизацию, тогда да… Ну, еще это в enterprise тестируют, я слышал…

Про API полезно знать любому тестировщику. А вот и нет! И это взаимодействие вы видите каждый день даже на самых простых и захудалых сайтах.
Потому что по нему системы взаимодействуют между собой.

Купил билет в кино? Любая оплата идет через API платежной системы. Книжку? Маечку в онлайн-магазине? Как только жмешь «оплатить», сайт соединяет тебя с платежной системой.

Но даже если у вас нет интеграции с другими системами, у вас всё равно есть API! Потому что система внутри себя тоже общается по api. И пока фронт-разработчик усиленно пилит GUI (графический интерфейс), вы можете:

  • скучать в ожидании;
  • проверять логику работы по API

Конечно, я за второй вариант! Так что давайте разбираться, что же такое API.

Что такое API

image

«Ко мне можно обращаться так и так, я обязуюсь делать то и это». API (Application programming interface) — это контракт, который предоставляет программа.

Договор между двумя сторонами, как договор на покупку машины: Если переводить на русский, это было бы слово «договор».

  • мои обязанности — внести такую то сумму,
  • обязанность продавца — дать машину.

Перевести можно, да. Но никто так не делает ¯\_(ツ)_/¯
Все используют слово «контракт». Так принято. К тому же это слово входит в название стиля разработки:

  • Code first — сначала пишем код, потом по нему генерируем контракт
  • Contract first — сначала создаем контракт, потом по нему пишем или генерируем код (в этой статье я буду говорить именно об этом стиле)

Мы же не говорим «контракт на продажу машины»? Вот и разработчики не говорят «договор». Негласное соглашение.

API — набор функций

Когда вы покупаете машину, вы составляете договор, в котором прописываете все важные для вас пункты. Точно также и между программами должны составляться договора. Они указывают, как к той или иной программе можно обращаться.

Соответственно, API отвечает на вопрос “Как ко мне, к моей системе можно обратиться?”, и включает в себя:

  • саму операцию, которую мы можем выполнить,
  • данные, которые поступают на вход,
  • данные, которые оказываются на выходе (контент данных или сообщение об ошибке).

image

Тут вы можете мне сказать:

Операция, данные на входе, данные на выходе — как-то всё это очень сильно похоже на описание функции! — Хмм, погоди.

Фактически у нас есть данные на входе, есть данные на выходе, и некая магия, которая преобразует одно в другое. Если вы когда-то сталкивались с разработкой или просто изучали язык программирования, вы наверняка знаете, что такое функция.

Вы будете правы в том, что определения похожи. И да! Да потому что API — это набор функций. Почему? Это может быть одна функция, а может быть много.

image

Как составляется набор функций

Да без разницы как. Как разработчик захочет, так и сгруппирует. Например, можно группировать API по функционалу. То есть:

  • отдельно API для входа в систему, где будет регистрация и авторизация;
  • отдельно API для отчетности — отчет 1, отчет 2, отчет 3… отчет N. Для разных отчетов у нас разные формулы = разные функции. И все мы их собираем в один набор, api для отчетности.
  • отдельно API платежек — для работы с каждым банком своя функция.
  • ...

image

Можно не группировать вообще, а делать одно общее API.

Если у вас коробочный продукт, то в него обычно входит набор стандартных функций. Можно сделать одно общее API, а остальные «под заказ». А любые хотелки заказчиков выносятся отдельно.

image

В каждом контракте четко прописано, какие операции можно выполнять, какие функции там будут Получается, что в нашей системе есть несколько разных API, на каждое из которых у нас написан контракт.

image

То есть одну и ту же функцию можно включать в разные наборы, в разные апи. И конечно, функции можно переиспользовать. Никто этого не запрещает.

image

Либо делает общее, либо распределяет по функционалу или каким-то своим критериям, и в каждое апи добавляет тот набор функций, который ему необходим. Получается, что разработчик придумывает, какое у него будет API.

При чем тут слово «интерфейс»

Ты же сама выше писала, что API — это Application programming interface. — Минуточку, Оля! Почему ты тогда говоришь о контракте, хотя там слово интерфейс?

Да потому, что в программировании контракт — это и есть интерфейс. В классическом описании ООП (объектно-ориентированного программирования) есть 3 кита:

  1. Инкапсуляция
  2. Наследование
  3. Полиморфизм

Инкапсуляция — это когда мы скрываем реализацию. Для пользователя все легко и понятно. Нажал на кнопочку — получил отчет. А как это работает изнутри — ему все равно. Какая база данных скрыта под капотом? Oracle? MySQL? На каком языке программирования написана программа? Как именно организован код? Не суть. Программа предоставляет интерфейс, им он и пользуется.

Это может быть SOAP, REST интерфейс, или другое API. Не всегда программа предоставляет именно графический интерфейс. Чтобы использовать этот интерфейс, вы должны понимать:

  • что подать на вход;
  • что получается на выходе;
  • какие исключения нужно обработать.

Пользователи работают с GUI — graphical user interface. Программы работают с API — Application programming interface. Им не нужна графика, только контракт.
Вызвать апи можно как напрямую, так и косвенно.

Напрямую:

  1. Система вызывает функции внутри себя
  2. Система вызывает метод другой системы
  3. Человек вызывает метод
  4. Автотесты дергают методы

Косвенно:

  1. Пользователь работает с GUI

Вызов API напрямую

1. Система вызывает функции внутри себя

Разные части программы как-то общаются между собой. Они делают это на программном уровне, то есть на уровне API!

И он же его потребитель! Это самый «простой» в использовании способ, потому что автор API, которое вызывается — разработчик. А значит, проблемы с неактуальной документацией нет =)

Просто в этом случае в качестве документации будут комментарии в коде. Шучу, проблемы с документацией есть всегда. Или разработчики разные, или один, но уже забыл, как делал исходное api и как оно должно работать… А они, увы, тоже бывают неактуальны.

2. Система вызывает метод другой системы

А вот это типичный кейс, которые тестируют тестировщики в интеграторах. Или тестировщики, которые проверяют интеграцию своей системы с чужой.

Она может попытаться получить данные из другой системы. Одна система дергает через api какой-то метод другой системы. Или наоборот, отправить данные в эту систему.

Допустим, я решила подключить подсказки из Дадаты к своему интернет-магазинчику, чтобы пользователь легко ввел адрес доставки.

И теперь, когда пользователь начинает вводить адрес на моем сайте, он видит подсказки из Дадаты. Я подключаю подсказки по API. Как это получается:

  • Он вводит букву на моем сайте
  • Мой сайт отправляет запрос в подсказки Дадаты по API
  • Дадата возвращает ответ
  • Мой сайт его обрабатывает и отображает результат пользователю

Вон сколько шагов получилось! И так на каждый введенный символ. Пользователь не видит этого взаимодействия, но оно есть.

И, конечно, не забываем про кейс, когда мы разрабатываем именно API-метод. Который только через SOAP и можно вызвать, в интерфейсе его нигде нет. Что Заказчик заказал, то мы и сделали ¯\_(ツ)_/¯

Метод MagicSearch создан на основе реальных событий. Пример можно посмотреть в Users. Хотя надо признать, в оригинале логика еще замудренее была, я то под свой сайт подстраивала.

Ну, может, парочка фильтров. Но тут фишка в том, что в самой системе в пользовательском интерфейсе есть только обычный поиск, просто строка ввода. А вот для интеграции нужна была целая куча доп возможностей, что и было сделано через SOAP-метод.

Функционал супер-поиска доступен только по API, пользователь в интерфейсе его никак не пощупает.

В этом случае у вас обычно есть ТЗ, согласно которому работает API-метод. Ваша задача — проверить его. Типичная задача тестировщика, просто добавьте к стандартным тестам на тест-дизайн особенности тестирования API, и дело в шляпе!

(что именно надо тестировать в API — я расскажу отдельной статьей чуть позднее)

3. Человек вызывает метод

Причины разные:

  1. Для ускорения работы
  2. Для локализации бага (проблема где? На сервере или клиенте?)
  3. Для проверки логики без докруток фронта

Если система предоставляет API, обычно проще дернуть его, чем делать то же самое через графический интерфейс. Тем более что вызов API можно сохранить в инструменте. Один раз сохранил — на любой базе применяешь, пусть даже она по 10 раз в день чистится.

Если мы хотим создать пользователя, надо заполнить уйму полей! Для примера снова идем в Users.

image

Но что, если вам нужны адекватные тестовые данные под вашу систему? Конечно, это можно сделать в помощью специальных плагинов типа Form Filler. И на русском языке?

А уж если это надо повторять каждую неделю или день на чистой тестовой базе — вообще кошмар. Заполнение полей вручную — грустно и уныло! Это сразу первый приоритет на автоматизацию рутинных действий.

Пользователя можно создать через REST-запрос CreateUser. И в данном случае роль автоматизатора выполняет… Postman. Профит! Один раз прописали нормальные “как настоящие” данные, каждый раз пользуемся.

При этом значения будут намного адекватнее. Вместо ручного заполнения формы (1 минута бездумного заполнения полей значениями «лпрулпк») получаем 1 секунду нажатия на кнопку «Send».

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

Если вы нашли баг и не понимаете, на кого его вешать — разработчика front-end или back-end, уберите все лишнее. Вызовите метод без графического интерфейса. А еще вы можете тестировать логику программы, пока интерфейс не готов или сломан.

4. Автотесты дергают методы

Есть типичная пирамида автоматизации:

  • GUI-тесты — честный тест, «как это делал бы пользователь».
  • API-тесты — опускаемся на уровень ниже, выкидывая лишнее.
  • Unit-тесты — тесты на отдельную функцию

image

Слово API как бы намекает на то, что будет использовано в тестах ツ

Допустим, у нас есть:

  • операция: загрузка отчета;
  • на входе: данные из ручных или автоматических корректировок или из каких-то других мест;
  • на выходе: отчет, построенный по неким правилам

Правила построения отчета:

  • Ячейка 1: Х — Y
  • Ячейка 2: Z * 6
  • ...

image

Открывает браузер, тыкает на кнопочки… Но если что-то упадет, будете долго разбираться, где именно. GUI-тесты — честный тест, робот делает все, что делал бы пользователь.

Мы просто подаем данные на вход и проверяем данные на выходе. API-тесты — все то же самое, только без браузера. Локализовать проблему становится проще. Например, можно внести итоговый ответ в эксельку, и пусть робот выверяет ее, правильно ли заполняются данные?

Отдельно смотрим расчет для ячейки 1, отдельно — для ячейки 2, и так далее. Unit-тесты — это когда мы проверяем каждую функцию отдельно. Такие тесты шустрее всего гоняются и баги по ним легко локализовать.

Косвенный вызов API

Когда пользователь работает с GUI, на самом деле он тоже работает с API. Просто не знает об этом, ему это просто не нужно.

У него есть кнопочка «загрузить отчет», на которую он и нажимает. То есть когда пользователь открывает систему и пытается загрузить отчет, ему не важно, как работает система, какой там magic внутри. Пользователь работает через GUI (графический пользовательский интерфейс).

image

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

image

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

Он вызвал сложное API, даже не подозревая об этом! И вот уже пользователь видит перед собой готовый отчет.

В первую очередь, мы подразумеваем тестирование ЧЕРЕЗ API. «Тестирование API» — общеупотребимый термин, так действительно говорят, но технически термин некорректен. Мы не тестируем API, мы не тестируем GUI (графический интерфейс). Мы тестируем какую-то функциональность через графический или программный интерфейс.

Можно использовать его и говорить “тестирование API”. Но это устоявшееся выражение. И когда мы про это говорим, мы имеем в виду:

  • автотесты на уровне API
  • или интеграцию между двумя разными системами.

Интеграция — когда одна система общается с другой по какому-то протоколу передачи данных. Это называется Remote API, то есть общение по сети, по некоему протоколу (HTTP, JMS и т.д.). В противовес ему есть еще Local API (он же «Shared memory API») — это то API, по которому программа общается сама с собой или общается с другой программой внутри одной виртуальной памяти.

image

Когда у нас есть две системы, находящихся на разных компьютерах, которые как-то между собой общаются. Когда мы говорим про тестирование API, чаще всего мы подразумеваем тестирование Remote API.

Хотя всегда стоит уточнить! И если вы видите в вакансии «тестирование API», скорее всего это подразумевает умение вызвать SOAP или REST сервис и протестировать его.

API (Application programming interface) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».

Контракт включает в себя:

  • саму операцию, которую мы можем выполнить,
  • данные, которые поступают на вход,
  • данные, которые оказываются на выходе (контент данных или сообщение об ошибке).
  • ».
Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть