Що таке голуторія

Що таке API

Слово «API» миготить у вакансіях навіть для тестувальників-початківців. Чи то REST API, чи то SOAP API, то просто API. Що це за звір такий? Давайте розумітися!

— А навіщо мені це? Я взагалі-то web тестую! Ось якщо піду в автоматизацію, тоді так… Ну, ще це у enterprise тестують, я чув…

А ось і ні! Про API корисно знати кожному тестувальнику. Тому що щодо нього системи взаємодіють між собою. І цю взаємодію ви бачите щодня навіть на найпростіших і найгірших сайтах.

Будь-яка оплата здійснюється через API платіжної системи. Купив квиток у кіно? Маєчку в онлайн-магазині? Книжку? Як тільки тиснеш "оплатити", сайт з'єднує тебе з платіжною системою.

Але навіть якщо у вас немає інтеграції з іншими системами, у вас є API! Тому що система в собі теж спілкується по api. І поки фронт-розробник посилено пиляє GUI (графічний інтерфейс), ви можете:

Що таке API

API (Application programming interface) - Це контракт, який надає програма. «До мене можна звертатися так і так, я зобов'язуюсь робити те і це».

Якщо перекладати російською, це було б слово «договір». Договір між двома сторонами, як договір на покупку машини:

мої обов'язки — внести таку суму,
обов'язок продавця – дати машину.

Code first - спочатку пишемо код, потім по ньому генеруємо контракт
Contract first — спочатку створюємо контракт, потім по ньому пишемо або генеруємо код (у цій статті я говоритиму саме про цей стиль)

API – набір функцій

Коли ви купуєте машину, ви складаєте договір, в якому прописуєте всі важливі для вас пункти. Так само і між програмами мають укладатися договори.Вони вказують, як до тієї чи іншої програми можна звертатися.

Відповідно, API відповідає на запитання "Як до мене, до моєї системи можна звернутися?", і включає:

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

Тут ви можете мені сказати:

— Хмм, постривай. Операція, дані на вході, дані на виході — все це дуже схоже на опис функції!

Якщо ви колись стикалися з розробкою або просто вивчали мову програмування, ви, напевно, знаєте, що таке функція. Фактично ми маємо дані на вході, є дані на виході, і якась магія, яка перетворює одне на інше.

І так! Ви будете праві в тому, що визначення схожі. Чому? Так тому що API – це набір функцій. Це може бути одна функція, а може бути багато.

Як складається набір функцій

Та все одно як. Як розробник схоче, так і згрупує. Наприклад, можна групувати API за функціоналом. Тобто:

окремо API для входу в систему, де буде реєстрація та авторизація;
окремо API для звітності - звіт 1, звіт 2, звіт 3 ... звіт N. Для різних звітів у нас різні формули = різні функції. І всі ми збираємо їх в один набір, api для звітності.
окремо API платіжок - для роботи з кожним банком своя функція.
.

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

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

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

І, звичайно, функції можна перевикористовувати. Тобто ту саму функцію можна включати в різні набори, в різні апі. Ніхто цього не забороняє.

Виходить, що розробник вигадує, яке він матиме API. Або робить загальне, або розподіляє по функціоналу або якимось своїм критеріям, і кожне апі додає той набір функцій, який необхідний.

До чого тут слово «інтерфейс»

— Хвилинку, Олю! Ти ж сама писала, що API - це Application programming interface. Чому ти тоді говориш про контракт, хоч там слово інтерфейс?

Та тому, що у програмуванні контракт — це і є інтерфейс. У класичному описі ООП (об'єктно-орієнтованого програмування) є 3 кити:

Не завжди програма надає графічний інтерфейс. Це може бути SOAP, REST інтерфейс або інше API. Щоб використовувати цей інтерфейс, ви повинні розуміти:

що подати на вхід;
що виходить на виході;
які винятки потрібно опрацювати.

Як викликається API

Викликати апі можна як безпосередньо, так і опосередковано.

Система викликає функції у собі
Система викликає метод іншої системи
Людина викликає метод
Автотести смикають методи

Виклик API безпосередньо

1. Система викликає функції у собі

Різні частини програми якось спілкуються між собою. Вони роблять це на програмному рівні, тобто на рівні API!

Це "найпростіший" у використанні спосіб, тому що автор API, яке викликається - розробник. І він його споживач! Отже, проблеми з неактуальною документацією немає =)

Жартую, проблеми з документацією є завжди.Просто в цьому випадку як документація будуть коментарі в коді. А вони, на жаль, теж бувають неактуальними. Або розробники різні, або один, але вже забув, як робив вихідне api і як воно має працювати.

2. Система викликає метод іншої системи

А ось це типовий кейс, який тестують тестувальники в інтеграторах. Або тестувальники, які перевіряють інтеграцію своєї системи із чужою.

Одна система смикає через api якийсь метод іншої системи. Вона може спробувати отримати дані з іншої системи. Або навпаки, надіслати дані до цієї системи.

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

Я підключаю підказки щодо API. І тепер, коли користувач починає вводити адресу на моєму сайті, він бачить підказки з Дадати. Як це виходить:

Він вводить букву на моєму сайті
Мій сайт надсилає запит у підказки Дадати по API
Дадата повертає відповідь
Мій сайт його обробляє та відображає результат користувачеві

І, звичайно, не забуваємо про кейс, коли ми розробляємо саме API-метод. Який тільки через SOAP можна викликати, в інтерфейсі його ніде немає. Що Замовник замовив, то ми і зробили

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

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

Функціонал супер-пошуку доступний тільки за API, користувач в інтерфейсі його ніяк не помацає.

У цьому випадку у вас зазвичай є ТЗ, згідно з яким працює API-метод. Ваше завдання – перевірити його. Типове завдання тестувальника, просто додайте до стандартних тестів на тест-дизайн особливості тестування API, і справа в капелюсі!

(що саме треба тестувати в API - я розповім окремою статтею трохи пізніше)

3. Людина викликає метод

Для прискорення роботи
Для локалізації бага (проблема де? На сервері чи клієнті?)
Для перевірки логіки без докруток фронту

Для прикладу знову йдемо до Users. Якщо ми хочемо створити користувача, треба заповнити безліч полів!

Звичайно, це можна зробити за допомогою спеціальних плагінів типу Form Filler. Але якщо вам потрібні адекватні тестові дані під вашу систему? І російською мовою?

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

І в цьому випадку роль автоматизатора виконує… Postman. Користувача можна створити через запит REST CreateUser. Одного разу прописали нормальні "як справжні" дані, щоразу користуємося. Профіт!

Замість ручного заповнення форми (1 хвилина бездумного заповнення полів значеннями "лпрулпк") отримуємо 1 секунду натискання на кнопку "Send". При цьому значення будуть набагато адекватнішими.

А ще у постмані можна зробити окрему папку підготовки тестової бази, напхати туди десяток запитів. І ось уже на будь-якій базі за пару секунд ви отримуєте стільки даних, скільки вручну вбивали б годинами!

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

4. Автотести смикають методи

Є типова піраміда автоматизації:

GUI-тести - чесний тест, "як це робив би користувач".
API-тести - опускаємось на рівень нижче, викидаючи зайве.
Unit-тести – тести на окрему функцію

Слово API ніби натякає на те, що буде використано в тестах

операція: завантаження звіту;
на вході: дані з ручних або автоматичних коригувань або інших місць;
на виході: звіт, побудований за деякими правилами

GUI-тести - Чесний тест, робот робить все, що робив би користувач. Відкриває браузер, тикає на кнопочки… Але якщо щось впаде, довго розбиратиметеся, де саме.

API-тести — все те саме, тільки без браузера. Ми просто подаємо дані на вхід та перевіряємо дані на виході. Наприклад, можна внести підсумкову відповідь в ексельку, і нехай робот вивіряє її, чи правильно заповнюються дані? Локалізувати проблему стає простіше.

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

Непрямий виклик API

Коли користувач працює з GUI, насправді він також працює з API. Просто не знає про це, йому це просто не потрібне.

Тобто, коли користувач відкриває систему і намагається завантажити звіт, йому не важливо, як працює система, який там magic всередині. У нього є кнопочка "завантажити звіт", на яку він і натискає.Користувач працює через GUI (графічний інтерфейс користувача).

Але насправді під цим графічним інтерфейсом користувача знаходиться API. І коли користувач натискає на кнопку, кнопка викликає функцію побудови звіту.

А функція побудови звіту вже може викликати 10 різних інших функцій, якщо це необхідно.

І вже користувач бачить перед собою готовий звіт. Він викликав складне API, навіть не підозрюючи про це!

Що означає "Тестування API"

Насамперед, ми маємо на увазі тестування ЧЕРЕЗ API. "Тестування API" - загальновживаний термін, так дійсно кажуть, але технічно термін некоректний. Ми не тестуємо API, ми не тестуємо GUI (графічний інтерфейс). Ми тестуємо якусь функціональність через графічний чи програмний інтерфейс.

Але це усталений вираз. Можна використовувати його та говорити “тестування API”. І коли ми про це говоримо, ми маємо на увазі:

автотести на рівні API
або інтеграцію між двома різними системами.

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

І якщо ви бачите у вакансії «тестування API», швидше за все це має на увазі вміння викликати SOAP або REST сервіс та протестувати його. Хоча завжди варто уточнити!