Всім привіт на зв'язку ! Можливо, багато хто знає про нас з . Для тих, хто підключився: ми розробляємо IDE для роботи з API TestMace. Найпоширеніше питання при порівнянні TestMace з конкуруючими продуктами - «Чим ви відрізняється від Postman?». Ми вирішили, що час дати розгорнуту відповідь на це питання. Нижче ми по пунктах розписали наші переваги перед .
Поділ на вузли
Якщо ви працюєте з Postman, знаєте, що інтерфейс запиту містить весь необхідний функціонал. Тут і скрипти, і випробування, і, власне, самі запити. Це спрощує роботу для новачків, проте на великих сценаріях такий підхід не є гнучким. Що, якщо хочеться створити кілька запитів і зробити за ними агрегацію? Що якщо хочеться виконати скрипт без запиту чи кілька логічно розділених скриптів поспіль? Зрештою, непогано було б відокремити тести від звичайних утилітарних скриптів. Крім цього, підхід «додаємо весь функціонал в один вузол» не масштабується - інтерфейс швидко стає перевантаженим.
TestMace спочатку поділяє весь функціонал різні типи вузлів. Хочеш зробити запит? Ось тобі вузол. Хочеш написати скрипт? Ось тобі вузол. Потрібні випробування? Будь ласка - вузол. Ах так, ви ще можете загорнути всю цю справу в вузол. І все це легко одне з одним поєднується. Такий підхід не тільки дуже гнучкий, а й відповідно до принципу єдиності відповідальності дозволяє використовувати тільки те, що тобі дійсно потрібно в даний момент. Навіщо мені скрипти та тести, якщо я хочу просто зробити запит?
Форма проекту, що читається,
Між TestMace та Postman є концептуальна відмінність у способі зберігання. У Postman всі запити зберігаються десь у локальному сховищі. Якщо є потреба розшарити запити між кількома користувачами, потрібно скористатися вбудованою синхронізацією. Насправді, це загальноприйнятий підхід, не позбавлений недоліків. Як щодо безпеки даних? Адже політика деяких компаній може не дозволяти зберігати дані у третіх осіб. Однак ми вважаємо, що TestMace може запропонувати дещо краще! І ім'я цьому покращенню — «людяний формат проекту».
Почнемо з того, що у TestMace в принципі є сутність "проект". І додаток спочатку розроблявся з прицілом на зберігання проектів у системах контролю версій: дерево проекту практично один в один проектується на файлову структуру, як формат зберігання використовується yaml (без зайвих дужок та ком), а файлове подання кожного вузла детально описано в документації з коментарями . Але здебільшого ви туди заглядати не будете - всі імена полів мають логічні назви.
Що це дає користувачеві? Це дозволяє гнучко змінювати воркфлоу команди, користуючись звичними підходами. Наприклад, розробники можуть зберігати проект у тому ж репозиторії, як і backend. У гілках, окрім зміни безпосередньо кодової бази, розробник може виправити наявні сценарії запитів та тести. Після фіксування змін у репозиторії (git, svn, mercurial - що вам більше подобається) CI (ваша кохана, ніким не нав'язана) запускає нашу консольну утиліту , а отриманий після виконання звіт (наприклад, у форматі junit, який також підтримується testmace-cli) відправляється у відповідну систему. Та й вищезазначене питання з безпекою вже не є проблемою.
Як бачите, TestMace не нав'язує свої екосистеми та парадигми. Натомість він легко вбудовується в процеси, що вже устали.
Динамічні змінні
TestMace слідує концепції no-code: якщо проблему можливо вирішити без використання коду, ми намагаємося дати таку можливість. Робота зі змінними це саме той функціонал, де здебільшого можна обійтися без програмування.
Приклад: нам надійшла відповідь від сервера, і ми хочемо зберегти частину відповіді в змінну. У Postman ми б у тестовому скрипті (що саме собою дивно) написали щось на кшталт:
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", jsonData.data);Але на нашу думку, написання скрипта для такого простого сценарію, що часто використовується, виглядає надмірно. Тому в TestMace є можливість присвоїти змінній шматок відповіді, використовуючи графічний інтерфейс. Погляньте наскільки це просто:
І тепер при кожному запиті ця динамічна змінна оновлюватиметься. Але ви можете заперечити, аргументуючи тим, що підхід постмана гнучкіший і дозволяє не просто зробити привласнення, а ще й виконати деяку передобробку. Ось як можна модифікувати попередній приклад:
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("data", CryptoJS.MD5(jsonData.data));Що ж, для цього у TestMace є вузол, який і покриває цей сценарій. Для того, щоб відтворити попередній кейс, але вже у виконанні TestMace, слід за запитом створити script вузол і як скрипт використовувати наступний код:
const data = tm.currentNode.prev.response.body.data;
tm.currentNode.parent.setDynamicVar('data', crypto.MD5(data));Як бачите, композиція вузлів і тут послужила хорошу службу. А для такого простого випадку, який описаний вище, ви взагалі можете просто привласнити вираз ${crypto.MD5($response.data)} змінної, що створюється через графічний інтерфейс!
Створення тестів через GUI
Postman дозволяє створювати тести за допомогою написання скриптів (у випадку Postman це JavaScript). Цей підхід має суцільні плюси — практично необмежену гнучкість, наявність готових рішень тощо.
Однак реалії часто такі (не ми такі, життя таке), що тестувальник не має навичок програмування, а користь команді хотілося б приносити вже зараз. Для таких випадків, за концепцією no-code, TestMace дозволяє створювати прості тести через графічний інтерфейс, не вдаючись до написання скриптів. Ось, наприклад, як виглядає процес створення тесту, який порівнює значення на рівність:
Проте створення тестів у графічному редакторі не скасовує можливість . Тут все ті ж бібліотеки, що і в script вузлі, і для написання тестів
Можливість запустити вже існуючий сценарій посилання (Link вузол)
Найчастіше виникають такі ситуації, коли певний запит чи навіть цілий сценарій необхідно виконати кілька разів у різних частинах проекту. Прикладом таких запитів може бути кастомна багатоетапна авторизація, приведення оточення до потрібного стану тощо. Загалом, якщо говорити в термінах мов програмування, хотілося б мати функції, які можна перевикористовувати в різних частинах програми. У TestMace цю функцію виконує вузол. Використовувати його дуже просто:
1) створіть запит або сценарій
2) створіть вузол типу Link
3) у параметрах вкажіть посилання на сценарій, створений на першому кроці
У більш просунутому варіанті ви можете вказати, які динамічні змінні зі сценарію прокидати на рівень вище щодо посилання. Звучить заплутано? Допустимо ми створили Folder з ім'ям create-post, всередині якого даний вузол призначається динамічна змінна postId. Тепер у Link вузлі create-post-link ви можете явно вказати, щоб змінна postId призначалася предку create-post-link. Даний механізм (знову-таки, висловлюючись програмісткою мовою) можна використовувати для повернення результату з функції. Загалом круто, DRY на повне зростання і знову жодного рядка коду не постраждало.
Що стосується Postman, то feature request на перевикористання запитів , і начебто навіть є , що над цією проблемою працюють. У поточному вигляді Postman звичайно має можливість зміни потоку виконання, що теоретично, напевно, дозволяє реалізувати подібну поведінку, але це швидше брудний хак, ніж дійсно робочий підхід.
Інші відмінності
- Більший контроль за областю видимості змінних. Найменшим скоупом, всередині якого можна визначити змінну Postman, є collection. TestMace дозволяє визначити змінні для будь-якого запиту чи папки. У Postman Share collection дозволяє експортувати лише колекції, тоді як у TestMace шаринг працює для будь-якого вузла
- TestMace підтримує , які за замовчуванням можуть підставлятися дочірні запити. У Postman із цього приводу є , і вона навіть закрита, але як рішення пропонується… . У TestMace це все конфігурується через GUI і є можливість опціонального відключення успадкованих заголовків у конкретних нащадках
- Undo/Redo. Працює не тільки при редагуванні вузлів, але і при переміщенні, видаленні, перейменуванні та інших операціях, які змінюють структуру проекту
- Файли, прикріплені до запитів, стають частиною проекту і зберігаються разом із ним, у своїй чудово синхронізуються, на відміну Postman. (Так, більше не потрібно щоразу вручну вибирати файли при кожному запуску та передавати колегам в архівах)
Фічі, які вже на підході
Ми не змогли встояти від спокуси відкрити завісу таємниці над наступними релізами, тим більше, коли функціонал дуже смачний і вже проходить передрелізне шліфування. Отже, зустрічаємо.
Функції
Як відомо, для генерації значень Postman використовуються так звані динамічні змінні. та переважна більшість функцій служать для генерації фейкових значень. Наприклад, для створення рандомного email необхідно написати:
{{$randomEmail}}Однак, оскільки це змінні (нехай і динамічні), їх не можна використовувати як функції: вони не параметризуються, тому взяти хеш від рядка не вийде.
У TestMace ми плануємо додати "чесні" функції. Прямо всередині ${} можна буде не тільки звернутися до змінної, а й викликати функцію. Тобто. якщо потрібно згенерувати горезвісний фейковий email, ми просто напишемо
${faker.internet.email()}Крім того, що це функція, можна помітити, що є можливість викликати метод об'єкта. І замість великого плоского списку динамічних змінних ми маємо набір логічно згрупованих об'єктів.
А якщо ми хочемо порахувати хеш від рядка? Легко!
${crypto.MD5($dynamicVar.data)}Можна помітити, що як параметри навіть можна передавати змінні! У цьому місці допитливий читач може запідозрити недобре.
Використання JavaScript у виразах
… І не дарма! Коли формувалися вимоги до функцій, ми раптом дійшли висновку, що у виразах потрібно давати писати валідний JavaScript. Тому тепер ви вільні писати вирази в дусі:
${1 + '' + crypto.MD5('asdf')}І все це без скриптів прямо на полях введення!
Що стосується Postman, то тут тільки можна використовувати змінні, і, при спробі написати трохи вираз, валідатор лається і відмовляється його обчислювати.
Просунуте автодоповнення
На даний момент TestMace має стандартне автодоповнення, яке виглядає так:
Тут крім автодоповнюваного рядка вказується до чого належить цей рядок. Працює цей механізм лише у виразах, обрамлених дужками ${}.
Як можна помітити, додалися візуальні маркери, які вказують на тип змінної (наприклад, рядок, число, масив тощо). Також можна змінювати режими автодоповнення (наприклад, можна вибрати автодоповнення змінними або заголовками). Але навіть це не найголовніше!
По-перше, автодоповнення працює навіть у виразах (де це можливо). Ось як це виглядає:
І по-друге, тепер автодоповнення доступне і у скриптах. Подивіться, як це працює!
Даний функціонал порівнювати з Postman немає сенсу - там автодоповнення обмежується лише статичними списками змінних, заголовків та їх значень (виправте мене, якщо я що забув). Скрипти не доповнюються авто 🙁
Висновок
У жовтні виповнився рік початку розробки нашого продукту. За цей час ми встигли зробити багато чого та за деякими параметрами наздогнали наших конкурентів. Але як би там не було, наша мета – зробити справді зручний інструмент для роботи з API. Нас чекає ще багато роботи, ось зразковий план розвитку нашого проекту на найближчий рік: .
Ваш фідбек дозволить нам краще зорієнтуватися в достатку фіч, а ваша підтримка - надає нам сил і впевненості в тому, що ми робимо потрібну справу. Так вийшло, що сьогодні важливий день для нашого проекту – день публікації TestMace на . Будь ласка, підтримайте наш проект, це дуже важливо для нас. Тим більше, що на нашій PH сторінці сьогодні приваблива пропозиція, і вона обмежена
Джерело: habr.com