Tutorial Karate Framework: proves automàtiques d'API amb Karate

karate framework tutorial

Aquest tutorial és una introducció a les proves API mitjançant Karate Framework. Obteniu més informació sobre l'estructura del Karate Test Script i els passos per construir el primer script de prova:

API és un acrònim que significa Interfície de programació d'aplicacions. En termes senzills, el podem definir com un intermediari de programari que permet la comunicació entre aplicacions.

Necessitem proves API perquè:

• Els resultats es publiquen més ràpidament, de manera que ja no esperareu si l'API funciona bé.
• Amb una resposta més ràpida, el desplegament d’aquestes API també es fa més ràpid, de manera que permet un temps de resposta ràpid.
• La detecció precoç d’errors, fins i tot abans de crear la interfície d’usuari de l’aplicació, ens permet mitigar els riscos i corregir els errors.
• Lliurament a gran escala possible en un període més curt.

Per poder treballar en proves d’API, tenim diverses eines disponibles al mercat com Postman, Mocha i Chai. Aquests han demostrat bons resultats i un ús eficaç per provar les API, tot i que tenen una gran influència del codi. Per poder-los utilitzar, cal ser tècnicament sòlid i familiaritzat amb els llenguatges de programació.

Karate Framework resol molt bé aquest problema de les seves eines de programari anteriors.

Què aprendreu:

• Què és Karate Framework
  • Història del marc de karate
• Comparant el Karate amb la seguretat
  • Eines necessàries per treballar amb Karate Framework
  • Estructura del guió de proves de karate
  • Creació del primer script bàsic de proves de karate
• Conclusió
  • Lectura recomanada

Què és Karate Framework

Karate? Parlem de karate. És el del Japó? Què penses? Podria ser que el gran Bruce Lee ho hagués desenvolupat durant el seu temps lliure.

Tot i que ens agradaria aprofundir en les interessants arrels del Karate, ara per ara parlem del Eina de karate que ha estat desenvolupat per Peter Thomas , una de les grans eines que serveixen per rescatar els provadors d'API.

El marc Karate segueix l'estil Cucumber d'escriure el programa que segueix l'enfocament BDD. La sintaxi és fàcil d’entendre pels no programadors. I aquest marc és l'única eina de prova de l'API que ha combinat l'automatització de l'API i les proves de rendiment en una sola eina independent.

Proporciona als usuaris la possibilitat d'executar els casos de prova en paral·lel i realitzar les comprovacions JSON i XML.

Amb aquesta informació, es poden deduir certs punts clau per entendre amb més detall l'eina Karate:

• El karate és un marc de proves de BDD en lloc d'un TDD.
• Està dissenyat per ser fàcil per als no programadors. Aquesta característica canvia el joc, ja que permet més ús i accés per a moltes persones independentment de la seva formació tècnica o capacitat.
• Utilitza el fitxer de funcions Cucumber i el llenguatge Gherkins per escriure la prova, que és molt fàcil d’entendre.

Totes aquestes funcions el converteixen en una de les eines d'automatització més favorables disponibles avui en dia.

Història del marc de karate

Creat per ' Peter Thomas ’ el 2017, aquest programari pretén que les funcionalitats de prova siguin fàcilment disponibles per a tothom. Es va escriure en Java i la majoria de la gent esperava que els seus fitxers també estiguessin en el mateix llenguatge, però, per sort, no és així.

Més aviat, utilitza fitxers Gherkins, que és el resultat de la seva relació amb el framework Cucumber. El programari d'automatització és una extensió de Cucumber, per tant, hereta l'ús del fitxer Gherkins en el seu funcionament. La gran diferència entre tots dos és que el Karate no fa ús de Java durant les proves, però el Cogombre sí.

Aquesta és la raó per la qual atén els no programadors, ja que la sintaxi de Gherkins és molt fàcil de llegir i completa. Aquesta és la raó per la qual el Karate és el més adequat i recomanat per fer una entrada al món de les proves API automatitzades.

A continuació es detallen algunes característiques del marc de proves de karate:

• Utilitza un llenguatge Gherkins fàcil d’entendre.
• No requereix coneixements de programació tècnica com Java.
• Es basa en els populars estàndards de Cogombre.
• Fàcil de crear un marc.
• Les proves paral·leles són la funcionalitat bàsica que proporciona el propi Karate, de manera que no necessitem dependre Maven, Gradle , Etc.
• IU per depurar la prova.
• Crida a un fitxer de funcions des d’un altre fitxer.
• Proporciona suport per a la prova del controlador de dades que es construeix a casa, per tant no cal dependre de marcs externs.
• Informes de repòs natius integrats. A més, es pot integrar amb el Cogombre per obtenir millors informes d’interfície d’usuari i més claredat.
• Proporciona suport intern per canviar la configuració en diferents entorns de proves (QA, Stage, Prod, Pre-Prod).
• Suport perfecte per a la integració de CI / CD que pot ser útil.
• Capaç de gestionar diverses trucades HTTP:
  • Suport de Web Socket
  • Sol·licitud SOAP
  • HTTP
  • Gestió de cookies del navegador
  • HTTPS
  • Dades de formulari HTML
  • Sol·licitud XML

Comparant el Karate amb la seguretat

Estigues segur : És una biblioteca basada en Java per provar els serveis REST. Utilitza un llenguatge Java per escriure les línies de codi. Ajuda a provar nombroses categories de sol·licituds, cosa que dóna lloc a la verificació de diferents combinacions de lògica empresarial.

Marc Karate : Una eina basada en Cogombre / Cogombres, que s’utilitza per provar els serveis SOAP & REST.

La taula següent mostra algunes diferències més destacades entre Rest-Assured i Karate Framework:

Per tant, com demostren les diferències anteriors, és segur dir que el karate és una de les coses més fàcils que qualsevol pot fer.

Eines necessàries per treballar amb Karate Framework

Ara, ja que tenim a punt els nostres coneixements bàsics sobre Karate Framework, vegem els processos i les eines necessàries per configurar l’entorn de Karate.

# 1) Eclipsi

Eclipse és un entorn de desenvolupament integrat utilitzat en el camp de la programació per ordinador. S'utilitza principalment per a la programació de Java. Com es va esmentar anteriorment, Karate està escrit en Java, de manera que té més sentit per què Eclipse és el IDE per al programari de prova API. Una altra raó és que és una eina de codi obert, i aquesta és una raó força forta per optar per aquesta eina.

Nota: Fins i tot podríem utilitzar IntelliJ, Visual Studio i altres editors diferents disponibles al mercat.

# 2) Maven

Es tracta d’una eina d’automatització de compilacions que s’utilitza principalment per construir projectes Java. És una manera de configurar un entorn de karate i escriure el codi. Per configurar el vostre Eclipse amb els requisits de Maven, podeu fer clic a aquí per a la instal·lació de Maven.

Mentre treballeu a Maven, utilitzeu dependències de Maven que us ajudaran a donar suport a Karate Framework.

Les dependències següents s’utilitzaran amb Maven a pom.xml.

Nota: És possible que les darreres versions estiguin disponibles al dipòsit de Maven.

com fer una matriu de cadena java

# 3) Gradle

Gradle és una alternativa a Maven i es pot utilitzar amb la mateixa capacitat. Tenen les seves similituds i diferències, però es poden utilitzar igualment per establir un entorn per als nostres codis de karate.

És més fàcil d'utilitzar, flexible i es recomana utilitzar quan la nostra aplicació té alguns requisits de modularització i gestió amb una gran quantitat de connectors. El codi de configuració de Gradle tindria un aspecte semblant,

Nota: Podeu utilitzar-lo MAVEN o bé GRAU.

# 4) Configuració de l'entorn Java al vostre sistema

Cal configurar l’entorn JDK i JRE per començar a utilitzar els scripts Karate Framework.

Estructura del guió de proves de karate

Un guió de prova de karate és conegut per la possessió de l'extensió '.feature'. Aquesta propietat s’hereta de Cogombre. L'organització de fitxers en la convenció de Java també està igualment permesa. Podeu organitzar els vostres fitxers segons les convencions del paquet Java.

Tot i això, les directrius de Maven indiquen que l’emmagatzematge de fitxers que no siguin Java es faci per separat. Es fan en un src / test / resources estructura. I els fitxers Java es mantenen sota src / main / java .

Però, segons els creadors de Karate Framework, creuen fermament que mantenim els fitxers Java i no Java junts. Segons ells, és molt més fàcil buscar els fitxers * .java i * .feature quan es mantenen junts, en lloc de seguir l'estructura estàndard de Maven.

Això es pot fer fàcilment ajustant el vostre pom.xml de la manera següent (per a Maven):

A continuació es mostra l’esquema de l’estructura general de Karate Framework:

Ara, ja que aquest Karate Framework utilitza el fitxer Runner, que també es necessita a Cucumber per executar els fitxers de característiques, de manera que la major part de l'escriptura seguirà els estàndards de Cucumber.

Però, a diferència del cogombre, els passos no requereixen una definició clara al karate i que, al seu torn, milloren la flexibilitat i la facilitat d’operacions. No necessitem afegir la cola addicional que hem d’afegir normalment quan seguim el marc del Cogombre.

La majoria de les vegades s’anomena la classe “Runner” TestRunner.java.

A continuació, el fitxer TestRunner.java prendrà la forma de:

I parlant de la .característica , conté tots els escenaris de prova que cal provar per assegurar-vos que l'API funciona segons els requisits esperats.

Un fitxer general * .feature té el següent aspecte:

Creació del primer script bàsic de proves de karate

Aquesta secció us ajudarà a començar amb la creació del vostre primer script de prova, que us serà útil per convertir les API en forma de marc Karate.

Abans d’escriure els scripts bàsics de prova de Karate, instal·leu els requisits següents al vostre equip:

• IDE Eclipse
• Maven. Establiu el camí adequat de Maven.
• JDK i JRE. Establiu el camí adequat.

Vegem l'enfocament pas a pas:

# 1) Crea un nou MAVEN Projecte a Eclipse Editor

• Obre Eclipsi
• Feu clic a Fitxer. Seleccioneu Projecte nou.

• Seleccioneu Projecte Maven

• Trieu la ubicació de l’espai de treball.
• Seleccioneu l'arquetip (normalment escollim ' Maven-archetype-quickstart 1.1 ”Per a projectes senzills de Maven).
• Proporcioneu l’identificador de grup i l’identificador d’artefacte (hem utilitzat els valors següents al nostre exemple).
  • Identificador de grup : Karate
  • Identificador d'artefacte: KarateTestScriptsSample
• Feu clic a Finalitza per completar la configuració.

# 2) Un cop creat, ara podreu veure l'estructura següent a la finestra de l'Explorador de projectes.

# 3) Incloeu totes les vostres dependències.

El nostre primer pas, després de la configuració, farem inclou totes les dependències que serà necessari per a l'execució. Conservarem totes les etiquetes a sota de POM.xml (suposant que ja sou conscient de l’ús de POM.xml).

• Obriu POM.xml i copieu el codi següent sota l’etiqueta de dependència i deseu el fitxer.

Feu clic a aquí per a la font.

# 4) Fem una pluja d’idees sobre l’escenari, què anem a provar en aquest guió de proves bàsiques de karate.

Escenari:

Provarem una API amb això URL.

Camí: api / users / 2

Mètode: ACONSEGUIR

I hem de validar , si la sol·licitud està retornant un Codi d'èxit (200) o no.

En termes senzills, només provarem una API d’exemple per veure si s’executa o no amb èxit.

Nota: Prenem una mostra d’API que està disponible per provar-la. Podeu triar qualsevol PATH o fer referència a la vostra API.

Feu clic a aquí per a la font.

# 5) Ara el nostre següent pas seria crear un fitxer .característica dossier.

Com es va comentar a la secció d'introducció, fitxer .feature és la propietat que s'ha heretat de Cogombre. En aquest fitxer, escriurem els escenaris de prova que cal executar per realitzar la prova de l'API.

• Aneu a Carpeta src / test / java al vostre projecte.

• Feu clic dret sobre ell i creeu un fitxer nou - userDetails.feature. A continuació, feu clic al botó Finalitza.

Ara veureu el fitxer següent a la carpeta src / test / java

El Icona de color verd s'assembla a la .funció fi en Cogombre que acabem de crear.

• Un cop creat el fitxer, ara escriurem els nostres escenaris de prova que es comentaran a la secció següent.

# 6) Ja que tenim l’escenari i el buit. característica fitxer llest, ara comencem amb el nostre primer script. Comencem a codificar

Escriviu la següent línia de codi al fitxer userDetails.feature que hem creat al pas # 5:

Intentem comprendre els components que s’escriuen al fitxer anterior:

• Característica: La paraula clau explica el nom de la funció que estem provant.
• Antecedents: Aquesta és una secció opcional que es tracta com una secció de requisits previs. Es pot utilitzar per definir tot el que cal per provar l'API. Conté HEADER, URL i PARAM opcions.
• Escenari: Tots els fitxers de funcions que veureu tindran com a mínim una característica (tot i que pot donar-se múltiple escenaris). És la descripció del cas de prova.
• Dada: És el pas que cal executar abans de realitzar qualsevol altre pas de prova. És una acció obligatòria a realitzar.
• Quan: Especifica la condició que s’hauria de complir per realitzar el següent pas de prova.
• Després: Ens indica que hauria de passar en cas que la condició esmentada al document Quan està satisfet.

Nota: Totes les paraules clau esmentades són del llenguatge Gherkins. Aquestes són la forma estàndard d’escriure els scripts de prova amb Cucumber.

I algunes paraules més utilitzades al fitxer de funcions són:

• 200: És el codi d'estat / resposta que esperem (feu clic a aquí per a la llista de codis d'estat)
• ACONSEGUIR: És el mètode API com POST, PUT, etc.

Esperem que aquesta explicació us sigui fàcil d’entendre. Ara podreu relacionar-vos amb el que està escrit exactament al fitxer anterior.

Ara hem de crear un fitxer TestRunner.java

currículum de proves de programari per 1 any d'experiència

Com s'explica a la secció anterior, Cucumber necessita un fitxer Runner que seria necessari per executar el fitxer .característica que conté els escenaris de prova.

• Aneu a Carpeta src / test / java al vostre projecte

• Feu clic amb el botó dret a sobre i creeu un fitxer Java nou: TestRunner.java
• Un cop creat el fitxer, col·loqueu-hi les línies de codi següents:

• Test Runner és el fitxer que ara s'executarà per realitzar l'escenari desitjat que s'ha escrit al pas número 5.

# 7) Ara estem preparats amb els dos fitxers TestRunner.Java i userDeatils.feature. L’única tasca que ens queda és Correr el guió.

• Aneu al fitxer TestRunner.java i feu clic amb el botó dret sobre el fitxer tal com es mostra a la imatge següent.

• Trieu Executa com -> Prova Junit
• Ara, un cop seleccionat, començareu a observar que el cas de prova ja ha començat.
• Espereu que s'executi l'script de prova. Un cop fet, observareu alguna cosa com es mostra a la imatge següent a la finestra.

• Finalment, podem dir que hem creat amb èxit el nostre primer element bàsic Prova de guió utilitzant el Marc Karate.

# 8) Finalment, el marc Karate també proporciona una presentació d'informes HTML per a l'execució que s'ha realitzat.

• Aneu a Carpeta de destinació -> surefire-reports-> Aquí veureu el vostre informe HTML que podeu obrir.

** També us recomanem que obriu el mateix mitjançant el navegador Chrome per obtenir un aspecte i una aparença millor.

• A continuació, se us mostrarà l'informe HTML Escenaris i prova que s'ha executat per a l'escenari esmentat:

Conclusió

En aquest tutorial, hem comentat les proves de l'API, les diferents eines de prova disponibles al mercat i com Karate Framework és una opció millor en comparació amb els seus homòlegs.

Vam seguir un enfocament pas a pas per crear el nostre primer script de prova bàsic. Vam començar creant un element bàsic Projecte Maven a Eclipse IDE per crear un fitxer .feature, que conté tots els escenaris de prova i un fitxer Runner per executar el cas de prova esmentat al fitxer .feature.

Al final dels múltiples passos, podríem veure l'informe d'execució dels resultats de la prova.

Esperem que aquest tutorial sigui útil per als principiants a l’hora d’aprendre a construir el seu primer script de prova mitjançant Karate Framework i realitzar proves d’API. Aquest enfocament detallat pas a pas és una manera meravellosa d'executar i executar diverses proves a l'API.

SEGÜENT >>

Lectura recomanada

• Com configurar el marc de proves Node.js: tutorial de Node.js
• Parasoft SOAtest Tutorial: Eina de prova d'API sense script
• Tutorial de Mockito: marc Mockito per burlar-se de les proves unitàries
• Tutorial de proves API: una guia completa per a principiants
• Tutorial TestNG: Introducció a TestNG Framework
• Tutorial Jest: proves d'unitats de JavaScript mitjançant Jest Framework
• Tutorial de proves destructives i proves no destructives
• Com s'utilitza Postman per provar diferents formats de l'API?