Verbose, wordy variation of my presentation on my experience in using Postman. Slides are in Bulgarian.

1. Кеф и кофти при използването на Postman
Борислав Трайков
DevOps & TA Lead
Verint

2. Базиранa на личен опит
и впечатления

3. МАЗЕН UI и добър CLI

4. Postman (Builder) & Runner

5. #БЕЗМАЗНОЕПРАЗНО

6. GUI – различни поколения

7. GUI – има какво да се желае
• Визуални бъгове
• На моменти е прекалено опростен
• Малка зона за писане на скриптове – 20-30 реда
• Chrome app вариацията има някои ограничения, като
например липсващи Chrome Dev tools и Postman console
• Chrome app вариацията – най-популярната до момента -
може и да спре да съществува -
http://blog.getpostman.com/2016/08/23/using-the-postman-chro

8. HTTP заявки
Лесно се описват –
URL, headers и body.
Лесно е да имат добро
текстово описание
(description).

9. HTTP заявки
Допълнителни благини:
•Генериране на код за HTTP заявки
•Authentication
•Работа с cookies

10. HTTP заявки
Параметризация – 3 възможности за дефиниране на променливи, които да се
използват в URL-ите, както и request body-тата, така и в тестовете. Тези параметри
могат да бъдат:
• Специфични за средата – може да се посочи „среда“, т.е. набор от
променливи и техните стойности, срещу които да се правят HTTP заявките
• Глобални – глобални за Postman на текущия потребител
• Динамични – дефинирани чрез скрипт: postman.setEnvironmentVariable(key,
value) или postman.setGlobalVariable(key, value)

11. HTTP заявки
• Автоматично добавени header-и – Postman, както и много
други HTTP клиенти добавят request header-и, обаче това
не е ясно директно докато си пишем HTTP заявките
• Някои header-и „не могат да се променят“

12. Chrome vs Windows app
HTTP заявки
В примера на следващия слайд ще видите различните „служебни“ header-и, които Postman добавя и на които автоматично
дава стойности.
Направена е POST заявка, която не се приема от крайния service. Причината се оказа, че крайния service (black box продукт,
който не може да бъде променян), приема HTTP имената на request header-ите като взема в предвид малки и главни букви
– case sensitivity.
Поради този факт HTTP заявката, изпратена от Windows-ския Postman не се възприема от service-a – нейният header
“Content-Length” е изписан с малки букви. Този header описва дължината на body-то на POST и PUT заявки.
Тогава service-а не възприема, че този header е подаден и от там – че няма и body с валидна дължина.
Проблемът обаче не се проявява при Chrome app вариацията на Postman.
Както можете да видите обаче, и в двете вариации на Postman някои header-и се предават, изписани само с малки букви.
Това може да се реши ако ние сами посочим тези header-и при изпращане на заявката.
Единственият проблем е “Content-Length”, тъй като за него се оказва, че не можем да назначим динамична стойност – само
статично число.

13. Chrome vs Windows app
HTTP заявки

14. Параметризация
• Environments (среди) – дефинираш едни и същи
променливи; слагаш различни стойности в
зависимост от средата. Могат да се запазват като
файл в JSON формат.
• Глобални променливи – не се променят от среда на
среда; например някакви общоизвестни съобщения
или кодировки

15. • Environments (среди) – още един (JSON) файл, който
трябва да се поддържа и синхронизира между
колегите
• Глобални променливи – глобални, но за машината на
всеки един колега; може да доведат до „ама при мен
работи“ ситуации
Параметризация

16. Collections
• Групиране на HTTP заявките – също така могат да се
дават описания и организацията да стане още по-
разбираема и лесна за използване от един или
повече екипи
• Поддържа се импорт/експорт – има и съвместимост с
групите HTTP заявки в други системи - например
Swagger

17. • В Postman не е ясно кой е JSON файлът на хард
диска, в който се пази текущата колекция
• Можете да се натъкнете на грешка, че не може да се
импортне колекция, която сте експортнали без
проблем.
Проблемът се проявява рядко и то когато сте
експортнали колекцията във формат „версия 2“.
Решението е да експортнете наново, но във формат
„версия 1“
Collections

18. Newman
• NodeJS приложение – може да се използва на
различни операционни системи
• Има добре документирани възможности
• Може да ползва като NodeJS модул в по-голямо
NodeJS приложение
• Новите му версии са синхронизирани с тези на
Postman -
https://www.getpostman.com/apps#changelog

19. • Трябва да се обновява отделно от Postman
• NodeJS приложение – при възникнал проблем може да получите изключително неописателни грешки
• API-то на Newman в момента е версия №3; v2 все още се поддържа. Поради тази причина може да настъпи объркване от
използване на опции валидни за различните версии на API-то. Решение на проблема има – в миграционния наръчник може
да се види кои опции са валидни за v3 – така можем да се придържаме само към тях.
• Макар да се влагат усилия да се уеднаквят, Postman и Newman все още имат някои функционални разлики
• По подразбиране ако има дори един неуспешен тест, Newman излиза с exit код = 1. Под Windows това обаче всичко освен
нула се счита за код за неуспешно изпълнение.
В такъв случай системи като Jenkins, към които сте интегрирали Newman могат и да не отчетат изпълнението на вашите
тестове, макар че просто е имало гърмежи (test failures).
В крайна сметка човек може да се справи с тази особеност или с малко Windows cmd магия, или ако прочете за –-exitCode
параметъра на Newman: https://www.getpostman.com/docs/integrating_with_jenkins
• А вие пробвали ли сте да подкарвате NodeJS приложения на сървър, който няма достъп до Интернет? Възможно е, но е и
„много забавно“.
Newman

20. Писане на тестове
• Postman Runner
Графична среда за изпълнение
на тестовете върху цели
колекции. Предоставя и
възможност за data-driven
изпълнения на колекциите

21. Писане на тестове
• Lodash
• SugarJS
• tv4 JSON schema validator
• CryptoJS
• xml2Json(someStringVar)
• еval(<код на JS библиотека по наш избор>)
Налични библиотеки:

22. • Писането на преизползваем код е … примитивно:
Както е демонстрирано на следващия слайд, може да
се запамети целият код на тестовете в променлива и
след това тя да се eval-не, така че кодът в нея –
запазен като string – да се изпълни като стандартен
JavaScript код.
Писане на тестове

23. Писане на тестове
Пример за глобална променлива, в която съхраняваме код за
тестове, които искаме да изпълняваме.
По този начин преизползваемият код ще се запази в environment
JSON файла.
Проблемът е, че ако този код трябва да се промени или дебъгне,
трябва да се извади от промеливата, да се промени и после пак
да се върне като стойност на тази променлива.

24. • По подразбиране всяка една проверка се счита за
тест, следователно 2 HTTP заявки, всяка с по 8 теста
в крайна сметка дава 16 теста. Това може да не е
търсеното от нас представяне на тестовете при
обобщаване на резултатите.
• Пак по подразбиране, всеки един тест в Postman е
прост булев израз – не се предоставя информация за
реалните и очакваните стойности … освен ако не си
ги принтираме сами, както е показано в следващия
слайд
Писане на тестове

25. Писане на тестове

26. Документация
• Има страшно много на официалния сайт (+ блога),
както и в GitHub хранилищата с кода на Postman и
Newman, така и в YouTube (+ oфициален канал)
• Общи усилия – Postman промотират хората, които
допринасят за развитието и разпознаваемостта на
продукта – чрез направата на обучителни материали,
доработки или интеграции с други продукти

27. • Базирана на стари версии – Postman и Newman са
преживяли не едно цялостно пренаписване, така че
• Най-новите неща все още не са описани –
обикновено ги има представени отгоре-отгоре в блог
пост или в някоя дискусия в GitHub или
StackOverflow
• Лиспва autocomple в самия Postman – при все, че
има вградени библиотеки.
Вече има подобрения в тази насока.
Документация

28. Благодаря!
Borislav Traykov
DevOps & TA Lead
Verint
https://www.linkedin.com/in/borislavtraykov/
https://www.facebook.com/borislav.t.traykov
https://twitter.com/turbobobi
www.qachallengeaccepted.com