API AL GRANO! (MATERIAL DE ESTUDIO)
PROYECTO CON API DE TRELLO:
https://developer.atlassian.com/cloud/trello/guides/rest-api/api-introduction/
https://developer.atlassian.com/cloud/trello/rest/api-group-boards/
1. INTRODUCCIÓN al API
Qué es una URL:
Las direcciones Web o «URLs» (Uniform Resource Locator) son la base de Internet y una forma sencilla de identificar y encontrar cualquier cosa que buscamos en la red como páginas web, fotos y videos.
URL es la abreviación de Dirección Web. El formato de una URL esta compuesto por varias partes: Protocolo, Dominio, Extensión, Recurso y Parámetros.
Encontramos URLs en el navegador web del ordenador y del teléfono:
En la barra de direcciones que está en la parte superior del navegador y sirve para escribir una dirección conocida.
En los enlaces o links que están en todas las páginas web y al pulsarlos sirven para saltar de una página web a otra, es lo que llamamos «navegar por internet».
Estructura de una URL o Dirección Web
Una dirección web está compuesta por varias partes que en su conjunto sirven para identificar y localizar cada página web, imágen o vídeo de Internet.
En este esquema vemos todas las partes de una URL:
Vamos a ver cada elemento, empezando por la izquierda:
Protocolo - Siempre está el primero por la izquierda e indica al navegador como tiene que acceder al recurso web que queremos ver. Es una cuestión técnica. Los protocolos que utilizan las páginas web son
http
yhttps
que es utilizado para las conexiones seguras identificadas por un cándado verde.
El protocolo está separado del resto de la dirección web con los caracteres://
.
En la parte central del esquema vemos la extensión del dominio, el famoso .com, o .es :
Extensión -o dominio de nivel superior (TLD)- Es la primera división que se hizo en Internet. Crearon divisiones genéricas
com
,net
,org
y una extensión para cada país del mundo:es
,co
,us
, etc.
Recientemente han aparecido nuevas extensionesblog
,tienda
,web
y muchas más debido a los pocos dominios libres que hay con las extensiones más comunes.
Mirando a la parte izquierda de la extensión (del .com)
La parte izquierda de la extensión sirve para localizar el servidor web que alberga el contenido que queremos ver.
Dominio - Es el nombre de tu sitio. Está a la izquierda de la extensión y están separados entre sí por un punto.
Cualquier persona o empresa puede registrar un dominio con una extensión (.com, .es,…) y por un tiempo (un año, dos años, cinco años o 10 años).
Luego, como propietario del dominio puede crear una página web o cuentas de correo electrónico.Subdominio - Un dominio también puede dividirse en subdominios.
Es algo opcional y crear subdominios es la técnica habitual para crear varias páginas web dentro del mismo dominio.
El subdominio más famoso eswww
pero hay más comoblog
,tienda
omail
.
A la derecha de la extensión
La zona derecha de la extensión sirve para localizar la página web, la imagen o el vídeo perteneciente al dominio. Está organizado del mismo modo que los ficheros del ordenador, es decir en directorios y ficheros.
Carpeta o subcarpeta- Es opcional y es el directorio o carpeta dentro del servidor dónde está el recurso.
Página o recurso - Es la página web, imagen o video que pertenece al dominio y que queremos ver.
Parámetros - Son opcionales. Al final de una URL pueden aparecer parámetros que sirven a los programadores para incluir información adicional que utilizan las páginas web para enviar información a los servidores, de forma que es posible dar ordenes o añadir la información de un formulario. Los parámetros están formados por una clave y su valor (clave=valor) y están separados del resto de los elementos de la URL por el caracter
?
.
2. INTRODUCCIÓN a POSTMAN (INSTALACIÓN)
INSTALACIÓN:
Utilidades de Postman:
2. AUTHORIZATION - SETUP DEL SUT
Como todo software, todo tiene su workflow y su manera de acceder, unas más comunes que otras, pero la realidad es que SIEMPRE debe haber una documentación al respecto.
En este Curso se utilizará el SUT: “Trello”,
el SW issue management especializado en metodología Kanban.En este se realizarán todas las prácticas de Testing real como en el laburo.
PRECONDICIONES PARA INICIAR:
Aquí se encuentra toda la Documentación API de Trello para Postman:
DOCUMENTACIÓN API DE TRELLO:
https://trello.com/signup → Crearse una cuenta de Trello (Obligatorio)
https://developer.atlassian.com/cloud/trello/guides/rest-api/api-introduction/ → Punto de partida para saber cómo empezar!
https://developer.atlassian.com/cloud/trello/rest/ → Full documentación CRUD para saber CÓMO usar el API de Trello
Authentication and Authorization - API KEY
Trello uses a delegated authentication and authorization flow so that your application never has to deal with storing or handling usernames or passwords. Instead, your application passes control to Trello (identifying itself via the API key) and once Trello has allowed the user to choose an account and sign in, Trello will hand the user and control back to your application, along with an API Token.
To get started, you’ll need an API key. You can get your API key by logging into Trello and visiting https://trello.com/app-key. Be sure to read and agree to Trello Developer Terms of Service. Your API key will be clearly labeled at the top of that page.
Your API key should be a 32 character string comprised of random alphanumeric characters. Because of the way the authorization flow works, the API key is intended to be publicly accessible. An API key by itself doesn't grant access to a user's Trello data. However, because API tokens grant access to the user's data, they should be kept secret.
For the purposes of this walkthrough, we'll have you generate a token for yourself. On the same page where you found your API key (https://trello.com/app-key), click the hyperlinked "Token" under the API key. You should be prompted with the following screen:
Your users will always see this screen when granting your application access. The permissions, duration of access, and application name displayed are all configured via the URL parameters. More on that at Authorization. But we'll leave everything as is, and click "Allow".
Once you click Allow
you'll grant your own app (identified via your API key) access to your account and be redirected to a page that contains the API token.
This token, along with your API key, can be used to read and write for your entire Trello account. Tokens should be kept secret!
3. HTTP REQUESTS
COMPONENTES DEL REQUEST
ADDRESS (URL)
REQUEST METHOD (GET, POST, PUT, DELETE, etc.)
PARAMETERS (Variables Key-Valor)
AUTHORIZATION (Tipos de Token para autenticar el Request)
HEADERS (API-key, Token, etc…)
BODY (Para hacer POST, PUT, UPDATE, etc.)
TESTS (Scripts para Validar los comportamientos del Request)
COMPONENTES DEL RESPONSE
STATUS CODE:
Más info en: Códigos de Estado HTTP
HEADERS (Respuesta del Header)
COOKIES (Respuesta de Cookies)
BODY (Puede ser en lenguaje JSON, como la mayoría actualmente, u otras como XML, HTML, etc)
4. VARIABLES DE SCOPES - usando esta Sintaxis: “{{}}”
Las Variables tienen algo llamado “SCOPES”
Son los siguientes: (se mostrarán con un ejemplo de ESQUEMA DE JERARQUÍA:
EN LOS SCRIPTS, SE USA ESTA QUERY PARA OBTENER EL SCOPE APROPIADO DEL REQUEST:
//Para POST pm.variables.set("",""); //Para GET pm.variables.get(""); //Para DELETE pm.variables.unset("");
🌍VARIABLES GLOBALES (Glovar) — Familia Var: El Abuelo
Cuando usarla?
Para propósitos generales, ideal para rápidos resultados y prototipos.
Mejores Prácticas:
Tratar de no usarlas mucho
Removerlas si no se necesitan ya.
Obtén variables en Scripts usando:
pm.globals.get("");
Grilla de la Variable:
<key>
Type:
Default
Secret
<Initial Value> (Visible)
<Current Value> (Hidden)
🏰VARIABLES ENVIRONMENTS (Amvar) — Familia Var: La Madre
Cómo usarla?
Ideal cuando se trabaja con diferentes ambientes (servidores)
Especialmente cuando en un Proyecto se trabaja con diferentes Ambientes de Pruebas:
Ejemplo realista (un URL por cada ambiente):
{{Dev}}; {{QA1}}; {{QA2}}; {{UAT}}; {{STAGE}}… etc.
Buena alternativa para variables globales.
Similar a las variables Globales pero con un scope específico
Ideal para cambiar entre diferentes setups
Usarlo para Autenticaciones o credenciales.
Para pasar data a otros Requests!
Mejores Prácticas:
Removerlas si no se necesitan ya.
No almacenar información específica de Environment.
Evitar confundirlos con Variables Globales
Obtén variables en Scripts usando:
pm.environment.get("");
Grilla de la Variable:
<key>
Type:
Default
Secret
<Initial Value> (Visible)
<Current Value> (Hidden)
📂VARIABLES PARA COLECCIONES (Colvar) — Familia Var: El Padre
Cómo usarla?
Asociados a una Collection en Postman
No pueden ser compartidos por múltiples collections.
Mejores Prácticas:
Usarlo con cualquier valor o constante
URL / credenciales de autenticación si solo existe un solo Environment.
Eliminar variables duplicados de Environements.
Obtén variables en Scripts usando según la conveniencia:
Grilla de la Variable:
<key>
<Initial Value> (Visible)
<Current Value> (Hidden)
🧪DATA (Datavar) — Familia Var: La Hermana Hija Mayor
Cómo usarla?
Usado cuando se trabaja con múltiples Datasets
Existe solamente durante la ejecución de una iteración (Query)
Usando una Query:
Puede ser establecido solamente desde un CSV o un JSON file.
5. PARAMETERS (Key-Valor)
PATH PARAMETERS
Es la continuidad de la ruta de una URL (parámetros separados por “/”)
Normalmente son la información REQUERIDA de una URL para un Post.
Siempre van primero antes de los Query Parameters
Postman puede detectar estos Path con la key “:” para colocar el valor Path Parameter:
Ejemplo:api.trello.com/:apiVersion/boards/:id …
donde “:api” y “:id” son Path Parameters (PP)
QUERY PARAMETERS (QP)
Son los campos específicos de un body
(parámetros comenzados por un “?” y separados por “&” en la URL)Normalmente son información opcional de una URL para hacer un Post, PERO algunos Query Parameters son OBLIGATORIOS.
Siempre van después del “?”
EQUIVALENCIAS DE INCIDENCIAS QA
con el WORKFLOW de API Testing (con Postman)
1. SINTAXIS DE LOS SCRIPTS DE PRUEBA:
En Postman, cada “test” es un Step del Caso de Prueba para validar.
La sintaxis inicial es siempre la misma:En cada SCRIPT siempre debe haber una “Assertion”, y a veces una “Variable” para hacer el Test.
Como en el ejemplo siguiente, un Assertion:El Assertion era:
Hay demasiados tipos de “Assertion” que se pueden usar (véase: https://www.chaijs.com/api/bdd/)
En caso de una Variable de Script, el ejemplo visual es el siguiente:
Se puede usar la declaración de variable dentro del bloque de código del test o fuera del mismo:
(En el ejemplo arriba se usó un Script para testear “Parámetros” del JSON recibido)
(Se recomienda siempre usar “const” para declarar una variable que será inmutable)
(En caso de que, por alguna razón, la variable será duplicada en el mismo script, se usa “let”)
IMPORTANTE A TOMAR EN CUENTA:
→ QUÉ VARIABLE DECLARAR EN LOS SCRIPTS: (Diferencia entre VAR vs LET vs CONST)RECOMENDACIÓN:
USAR SIEMPRE → “Console.log()” para poder ver y chequear los datos de los Objetos del Body antes de poder hacer los ASSERTIONS.
2. SCRIPTS para PARAMETERS:
Para poder encontrar un Parámetro y validarlo, se necesita conocer el JSON que se recibirá, para así saber hallar el nombre del parámetro y su valor (Key + Valor del Parámetro)
Ejemplo:En este caso, “idBoard”, es una Key que tiene el JSON que se obtuvo, y “body” es una variable creada previamente para definir “La Respuesta del JSON”. Y el “eql()” nos dice a qué debe ser igual nuestra Key del Body (por eso se comienza como “pm.expect(body.idBoard)” para establecer QUÉ SE ESPERA OBTENER).
Otros Ejemplos validando Parametros:Todo es cuestión de conocer el JSON y saber dónde se encuentra el Parámetro (Key-Valor) que queremos validar con el Script de Prueba.
Hay muchos tipos de Scripts de Testing, pero el de Parámetros es el más usado.
2. PRE-REQUEST SCRIPS
Para cada Request en una Collection, los Scripts se ejecutarán en el siguiente orden:
Un Script de Pre-Request asociado a una Collection(TS), correrá PRIMERO cada Request en la Collection.
Un Script de Pre-Request asociado a una Carpeta (TC), correrá PRIMERO cada Request en la Carpeta.
Un Script de Test asociado a una Collection(TS), correrá DESPUÉS cada Request en la Collection.
Un Script de Test asociado a una Carpeta (TC), correrá DESPUÉS cada Request en la Carpeta.
“PRE-REQUEST” Consiste en DEFINIR una VARIABLE DE SCOPE con una Declaración de Script.
Cuya ejecución será primero y antes de aparecer el Body del Response.
El Flujo sería:
(Primero, segundo, tercero)
PRE-REQUEST SCRIPTS = RUN THE HTTP REQUEST → RESPONSE BODY = TEST SCRIPTS
En la pestaña de Pre-Request Scripts, se puede hacer la siguiente Declaración. Ejemplo:
PARA LUEGO, En el TEST Scripts:
AL momento de Correr el Test, primero: se definirá la Variable de Scope (Environment) PREVIAMENTE, y luego: correrá el Test usando la Variable Scope definida.
((También se puede crear un Script para DESHACER la variable una vez finalice el Test, y así no guardará Variables de Scopes innecesariamente!))→ BÁSICAMENTE SE USA PARA SOBREESCRIBIR DATA / PREPARAR DATA
3. ASSERTIONS SCRIPTS
Los Assertions SIEMPRE van a estar en un Script de Prueba.
Para VALIDAR un resultado esperado, se deben usar Assertions SEGÚN EL BODY DE RESPUESTA DEL API.
Cada Software tiene su estructura de código presentada con sus API, las cuales pueden ser variadas, aunque la más común hoy en día es la de JSON por su adaptabilidad a cualquier lenguaje como todos sabemos.
A continuación se presentará cada SINTAXIS para HACER SCRIPTS SEGÚN EL “RESPONSE BODY”:
JSON →→ 🚩
XML →
HTML →
Plain-Text →
CSV →
CHAI ASSERTION LIBRARY:
DOCUMENTACIÓN DE CHAI ASSERTION:
QUIZ DE ASSERTIONS PARA LA CLASE: (COPIA Y PEGA EN EL SCRIPT para que aprecies el código.
DELIVERY QUIZ:
ENVÍA LA RESPUESTA AL PRIVADO Y TE DIRÉ TU PUNTUACIÓN
ASSERTIONS SCRIPTS en ARRAYS
Para validar un Parámetro (Key-Valor) QUE SE ENCUENTRA DENTRO DE UN ARRAY de un Body de JSON,
Se necesita usar los Corchetes “[]” para iterar y señalar el parámetro a validar:Aquí se hizo primero un script para encontrar un Parámetro DENTRO de un Array (backgroundImageScaled[5]), cuyo array se encuentra DENTRO de otro Array (“Body[0].prefs”) el cual se encuentra DENTRO del Body del Json (por eso se usa el “pm.response.json();” para definir el cuerpo del JSON y convertirlo en variable “Body”, para luego combinárlo con el otro script y convertirlo en la variable “altura” en este caso.
Luego de tener la ubicación del parámetro, se aplica el Scrit de Test para validar como siempre.AHORA: Para validar un Parámetro QUE NO SE SABE DÓNDE SE ENCUENTRA EL MISMO EN EL ARRAY,
Entonces en lugar de usar Corchetes “[]” se puede usar una función “For” para ITERAR y encontrarlo:
SCRIPT PODEROSO PARA ENCONTRAR CUALQUIER PROPIEDAD!
Usando el Chai Assertion: “.find(Objeto => Objeto.atributo === “valor”)”
Ejemplo:
Donde “i” es una auto-variable que está refiriéndose a TODA LA ARRAY como un “item”, y que a su vez está diciendo que la llave (atributo) debe ser exactamente igual al valor (valor de la propiedad). Y lo que hará es BUSCAR TODOS LOS MISMOS ATRIBUTOS pero se detendrá cuando encuentre el valor declarado.
PLUS: SCRIPTS CON CARACTERES ESPECIALES
Cuando se tiene “CARATERES ESPECIALES” dentro de una Propiedad, ya no se puede usar el mismo object notation “ object.object.object “, sino que se debería usar los Corchetes “[]” encerrando la palabra junto con las comillas. Ejemplo:
5. ASSERTIONS SCRIPTS para HEADERS y COOKIES
Además de Scripts para Status Code, Scope Parameters y Response Body, también hay para:
HEADERS y COOKIES.HEADERS:
Así se realiza un script para obtener un header desde el Response: (ejemplo)En un Test:
Si existe el Header:
Si el Header tiene un cierto valor:
COOKIES:
Similar al anterior, así se realiza el script para obtener las cookies: (ejemplo)En un Test:
Si existe las Cookies:
Si el Cookies tiene un cierto valor:
https://learning.postman.com/docs/writing-scripts/script-references/test-examples/
Assertion deep equality error
You may encounter the AssertionError: expected <value> to deeply equal '<value>'
. For example, this would arise with the following code:
This happens because the test is comparing a number to a string value. The test will only return true if both the type and value are equal.
Asserting the current environment
Check the active (currently selected) environment in Postman:
JSON not defined error
You may encounter the ReferenceError: jsonData is not defined
issue. This typically happens when you are attempting to reference a JSON object that hasn't been declared or is outside the scope of your test code.
Make sure that any code setting your response data to a variable is accessible to all test code, for example in this case moving const jsonData = pm.response.json();
before the first pm.test
would make it available to both test functions.
Asserting a value type
Test the type of any part of the response:
Asserting array properties
Check if an array is empty, and if it contains particular items:
Asserting object properties
Assert that an object contains keys or properties:
Target can be an
object
,set
,array
ormap
. If.keys
is run without.all
or.any
, the expression defaults to.all
. As.keys
behavior varies based on the targettype
, it's recommended to check thetype
before using.keys
with.a
.
Asserting that an object is contained
Check that an object is part of a parent object:
Using
.deep
causes all.equal
,.include
,.members
,.keys
, and.property
assertions that follow in the chain to use deep equality (loose equality) instead of strict (===
) equality. While the.eql
also compares loosely,.deep.equal
causes deep equality comparisons to also be used for any other assertions that follow in the chain, while.eql
doesn't.
Corriendo una Collection Enorme Automatizada desde Postman:
Corriendo una Collection CRUD Automatizada usando Newman desde la terminal:
((EL TEMARIO SERÁ SUBIDO LUEGO DEL JUEVES 5 DE MAYO))