Postman е инструмент за правене на HTTP заявки и добавяне на автоматизирани тестове към техните резултати. Смятам, че е важно да се има предвид, че поради тези две причини Postman може да се използва успешно както от отделни членове на екипа, така и при колаборация между цели екипи. В настоящата статия ще разкажа за интеграцията на автоматизираното извикване на Postman чрез Newman. Как, с какво да се внимава и какво можем да очакваме като резултати.

Има и някои подводни камъни разбира се – няма перфектен софтуер без хлъзгави моменти.

В статията ще положим, че читателят е запознат със следните концепции:

  1. Как се правят HTTP заявки с Postman
  2. Какво са колекции в Postman
  3. Как се пишат тестове в Postman
  4. Какво са среди (environments) в Postman
  5. Какво е newman

Кога да интегрираме автоматизация с Postman?

От гледната точка на екипи, които пишат и/или консумират HTTP API:

Ако имате възможност, използвайте фалшиви данни (dummy data), за да пускате заявките към функционалностите, които сте декларирали. Ползата, която можете да извлечете е, че дори без да имате прикачени тестове, вие можете:

  1. Да проверите, че текущата система – без значение на коя среда – може да свърши работа след всяко обновяване.

Друг пример за това са наблюдение/мониторинг на софтуера за отклонения в някои от функционалностите.

  1. Да използвате Newman като nodeJS приложение, което има и съответно JavaScript API, така че извикванията на HTTP заявките могат да се обогатят с връзки към бази данни, достъп до файлове по диска и извиквания на други nodeJS модули.

Ако имате прикачени тестове към HTTP заявки, то тогава към горепосочените ползи можете да добавите и автоматизирано изпълнение на тестове към описаните HTTP заявки.

Как да интегрираме автоматизация с Postman?

Следването на официалните инструкции дава доста добри резултати, така че предизвикателствата, които бихте срещнали са в спецификите. По-долу са моите препоръки и фактори, за които ви препоръчвам да внимавате.

Препоръки

  1. Пуснете всички видове доклади (reports) – ето защо:
    • Конзолният – дава ви информация „на живо“, както и историческа информация за изпълнението в системата, която е извикала
      Пример с Jenkins: конзолният лог на newman става част от конзолния лог на изпълнението на job-а, който е извикал newman
    • В JSON формат – Лесен за интеграция с JavaScript-базирани приложения.
      Наскоро с колегите установихме, че при много налични тестове в една колекция – повече от 400 – се получава доклад, който чупи реализацията по подразбиране. Проблемът е констатиран в GitHub, а вече има и няколко решения в NPM хранилището, най-популярното бидейки newman-reporter-json-light
    • В HTML формат – представителен и подходящ за всеки, който иска да види резултатите в обобщение и да задълбава само ако е необходимо.
  1. В XML формат – това всъщност е апокрифният JUnit XML формат за тестови доклади. Той е основният формат, който Jenkins може да разчете и да се прочете
  2. Newman би ви позволил да изпълнявате заявките и тестовете към тях в паралел – за жалост това все още нещо, което не се случва Един от хората работещи по Postman обаче дава пример как с малко nodeJS код може да се реализира паралелно изпълнение на колекции и технтие тестове: https://github.com/postmanlabs/newman/blob/896a7b61955ee59bc8bfcfa144e7c5aa3639194e/examples/parallel-collection-runs.js.
    За жалост горепосоченият пример не е интегриран като възможност на Postman runtime.
  3. Разгледайте няколко изпълнения – огледайте за грешки и предупреждения в лога на изпълнение. Може да се окаже, че имате фалшиво-позитивни и фалшиво-негативни тестове.
  4. Ако искате да правите мониторинг на дадено приложение/система, то можете да настроите CI система като Jenkins, която да извиква колекция от заявки през newman – така ще получите опростен и безплатен вариант на едно от свойствата на Postman Pro – Monitoring.
  5. Пуснете подробните логове, за да можете да проверите грешки при изпълненията на колекциите.

За какво да внимавате:

  1. Не забравяйте, че Postman и newman продължават да се развиват стремглаво. Има бъгове – проверявайте и ги докладвайте https://github.com/postmanlabs/newman/issues
  2. Под Windows изпълнението на колекции и техните тестове чрез newman по подразбиране ще излезе с exit code = 1. Ако това е част от по-голям процес, то този изходен код може да попречи следващи стъпки да бъдат изпълнени.
  3. Внимавайте за колекции във версии 1, 2 и 3 – Newman не би трябвало да има проблеми с която и да е версия, но с колегите имахме проблеми при работата с различни версии на колекциите. Един колега експортва общата колекция в тогавашната най-нова версия на колекциите v2, но част от колегите не можеха да я импортират. Всички бяха с една и съща версия на Решението беше да експортираме колекцията във v1, която се импортираше успешно от всички.
  4. API-то за тестове на Postman, а от там и на Newman се променя с по-новите версии. Може да се окажете в ситуация, в която код работещ в Postman, не работи в Просто Postman вади известие всеки път когато има по-нова версия, докато newman за жалост не дава такава индикация и се изисква внимание от страна на човека/хората, които са отговорни за обновяването на newman инсталацията.

 

Полезни препратки

Официалната Github страница на newman: https://github.com/postmanlabs/newman

Правилният и актуален списък промените във версиите на newman: https://github.com/postmanlabs/newman/blob/develop/CHANGELOG.md

Официална страница на newman npm пакета (съдържа и инфо за използването): https://www.npmjs.com/package/newman

Няколко статии за интеграции на newman с различни системи:
https://www.getpostman.com/docs/postman/collection_runs/integration_with_jenkins
https://www.getpostman.com/docs/postman/collection_runs/integration_with_travis
https://www.getpostman.com/docs/postman/collection_runs/newman_with_docker
Интеграция с Atlassian Bamboo – чрез JUnit доклади


>>> Борислав ръководи малък екип за DevOps и автоматизирано тестване във Веринт Системс България (Verint).
>>> Има сумарно 13 години опит в IT индустрията на различни позиции – техническа поддръжка и работа с клиенти, продажби, писане на софтуер, администриране на бази данни, тестване на различни видове приложения и автоматизация на процеси по доставянето на софтуерни решения.
>>> Макар сега да пише на PowerShell и Java, изявява предпочитания към C#, а и JavaScript не му е чужд.
>>> Любим софтуерен продукт: Microsoft SQL Server.


Стани част от потребителските групи на DEV.BG. Абонирай се и ще ти изпращаме информация за всичко, което предстои в групата.

Прочети още:
Разговор с Евгени Костадинов за работата му като Software Quality Assurance
„Автоматизацията в сегашната ера е като измислянето на трактора“ – Антон Ангелов, QA Architect, Progress

Share This