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

Open

(EDteam te amo jaja)

Open

Cultura General

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 y https 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 extensiones blog, 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 es www pero hay más como blog, tienda o mail.
  
  

   

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)

  • → Punto de partida para saber cómo empezar!

  • → Full documentación CRUD para saber CÓMO usar el API de Trello

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:

  • 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: )

  • 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:

1. Un Script de Pre-Request asociado a una Collection(TS), correrá PRIMERO cada Request en la Collection.

2. Un Script de Pre-Request asociado a una Carpeta (TC), correrá PRIMERO cada Request en la Carpeta.

3. Un Script de Test asociado a una Collection(TS), correrá DESPUÉS cada Request en la Collection.

4. 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:

      •  

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 or map. If .keys is run without .all or .any, the expression defaults to .all. As .keys behavior varies based on the target type, it's recommended to check the type 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))