Header Ads Widget

Ticker

6/recent/ticker-posts

¡No permita que los cambios de API lo golpeen como un tren de carga!

 

La mayoría de las aplicaciones web y muchas aplicaciones móviles se basan en API de terceros como inicio de sesión social, almacenamiento en la nube, correo electrónico, mensajería, CRM, etc. Los beneficios son obvios y, para algunas aplicaciones, la integración de API es un elemento central. Sin embargo, la dependencia de la API hace que las aplicaciones sean más vulnerables a los cambios : un pequeño cambio en una API puede romper una aplicación completa.

Los cambios de API son inevitables. Al igual que las aplicaciones de software tradicionales, las API pasan por cambios, revisiones y versiones. Las mejores prácticas están muy bien definidas para extender, versionar y reemplazar API, y los proveedores de API suelen tener una estrategia de administración de API implementada. Todo esto es genial, se espera.

La pregunta es, como consumidor de API, ¿tiene una estrategia para administrar los cambios de API de terceros ? Si un cambio de API interrumpe la aplicación, puede tener graves consecuencias; pérdida de datos, ingresos y usuarios, sin mencionar el daño a la reputación de la empresa. Sin un proceso implementado, los cambios de API de terceros pueden golpearlo como un tren de carga .

Hoy describimos algunos pasos que los consumidores de API pueden tomar para monitorear sus API y garantizar que ningún cambio importante interrumpa una experiencia de usuario que de otro modo sería serena. Como caso de estudio, veremos lo que los desarrolladores de CloudRail han hecho para mitigar de manera segura el uso de API de terceros y analizaremos una aplicación Node.js simple diseñada para ayudar en las pruebas de autenticación.

Supervisión de cambios

La buena noticia es que la mayoría de los proveedores de servicios API dan una temprana mano a mano antes de hacer cualquier cambio, lo que permite un montón de tiempo para hacer correcciones en su final. La pregunta es, ¿ quién recibe notificaciones sobre los cambios en la API?

El equipo de CloudRail monitorea las API que integran en sus SDK y, si hay algún cambio, pueden notificar a sus usuarios. Pero, ¿quién recibe la notificación? ¿Va a un correo electrónico grupal, al gerente de ingeniería (que ya se está ahogando en correos electrónicos) o tal vez a un empleado anterior?

Lección: Asigne un rol de mantenimiento de integración de API a un miembro específico del equipo . No se lo deje a quien descubrió el cambio, ya que eso deja las cosas al azar y la disponibilidad potencialmente irregular de los miembros del equipo.

Más sobre los equipos de API: evite caminar sobre cáscaras de huevo y use DevOps

Pruebas automatizadas

Las pruebas automatizadas son siempre un ingrediente clave para monitorear la funcionalidad de una aplicación. Si bien las pruebas automatizadas se realizan con mayor frecuencia en software interno, no deben limitarse al código interno, sino que deben aplicarse a todas las integraciones, incluidas las bibliotecas de terceros y las dependencias de API.

Detecte integraciones rotas con pruebas de extremo a extremo que simulan las solicitudes de los usuarios y prueban todas las funciones. Sin embargo, es importante recordar que las pruebas automatizadas están destinadas a validar la funcionalidad, no es una forma de identificar problemas.

Algunas funciones pueden ser difíciles de automatizar, lo que dificulta las pruebas. La belleza de probar la API de una aplicación (a diferencia del front-end de una aplicación) es que a la API no le importa dónde se realizan las solicitudes: las API REST que operan a través de HTTP enviarán las mismas respuestas JSON y mensajes de error a una aplicación móvil, web aplicación o servicio de terceros como un cliente de prueba Postman o un cliente de línea de comandos como Newman .

Algunas pruebas requieren un flujo de prueba más complejo, como la autenticación OAuth . Digamos que tenemos una aplicación que utiliza Facebook Social Login con almacenamiento de archivos de Dropbox y queremos obtener una lista de los archivos almacenados en Dropbox. Primero debemos autenticarnos a través de un flujo en el que le damos permiso a la aplicación para acceder a la cuenta de Dropbox una vez que se dan las credenciales.

Este proceso de autenticación requiere clics y redireccionamientos para funcionar, lo que significa que tenemos que simular la interacción del usuario . Esto se puede hacer con herramientas de prueba como Selenium Webdriver . A continuación, crearé una pequeña aplicación Node.js, con un componente de terceros para manejar la autenticación, y luego la probaré con Selenium Webdriver.

Lea también nuestra publicación sobre pruebas automatizadas para la documentación de API

Construyendo la Aplicación

La aplicación es muy sencilla; las rutas solo constan de “/” (raíz), “/ autorizar” y “/ auth”. Root carga una página con un enlace a la autorización y auth es una devolución de llamada para la autenticación. La API unificada de CloudRail se utiliza para manejar la autenticación de Dropbox. Aquí está el código fuente:


var express   =  require("express");
var app       = express();
var url       = "[ The applications URL ]"

const cloudrail = require("cloudrail-si");
cloudrail.Settings.setKey("[ App Key ]");

app.get('/',function(req,res){
  // Insert link to authorization on the webpage
  res.send("Authorize");
});

app.get('/auth',function(req,res){
  // Return status
  res.setHeader('Content-Type', 'application/json');
  res.send(JSON.stringify({ status: "OK", code: 200 }));
});

app.get('/authorize',function(req,res){
  
  // Setup CloudRail RedirectReceiver
  var redirectReceiver = (url, state, callback) => {
      res.redirect(url);
   };

   // Setup Dropbox service
  const dropbox = new cloudrail.services.Dropbox(
    redirectReceiver,
    "11uz2nxnttx24ks",
    "p9llxxo6mh6rg26",
    url + "/auth",
    "someState"
  );

  // Perform login
  dropbox.login(
    (error, result) => { }
  );
});

// Listen to requests on port 3000
app.listen(3000,function(){
  console.log("Listening on PORT 3000");
});


El código es muy simple y solo maneja el proceso de inicio de sesión. Una vez que se realiza la autenticación, el servicio DropBox se puede utilizar para obtener la lista de archivos, cargar y descargar archivos, y mucho más. Pero para este ejemplo de prueba, solo nos enfocamos en la autenticación .

Pruebas

Como se mencionó anteriormente, estamos usando Selenium Webdriver para este ejemplo, pero otras herramientas de prueba pueden hacer lo mismo. Algunas de las herramientas de prueba que se pueden usar para realizar pruebas, además de Selenium, incluyen SoapUI , RIATest y Ghost Inspector, y más herramientas específicas de lenguaje / framework como Mocha y QUnit. Qué herramienta elegir depende en gran medida de las necesidades y preferencias personales, aunque algunas tienen limitaciones. Por ejemplo, Ghost Inspector no puede manejar redireccionamientos a un host local, por lo que la aplicación debe estar disponible en un dominio público.

Suponemos que Eclipse, Selenium, WebDriver y el enlace de lenguaje Java están instalados y se crea un nuevo proyecto. Hay muchos tutoriales disponibles para estos pasos. Este tutorial de Guru99 hace un buen trabajo explicando la configuración. Aunque está escrito para usuarios de Windows, los pasos para los usuarios de Mac son muy similares, y los usuarios de Mac también pueden utilizar este tutorial.

Lo que quiero hacer es cargar la página raíz, hacer clic en un enlace para autorizar una cuenta de Dropbox (iniciar sesión con las credenciales del usuario y luego permitir el acceso) y devolver una devolución de llamada con el código de autenticación. Estas pocas líneas de código logran eso:


package newpackage;

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;

public class MyClass {
	public static void main(String[] args) {
		
    Integer TIMEOUT 			= 20;
    String APP_URL			  = "[ URL to the Node.js root ]";
    String USER_EMAIL 		= "[ Dropbox User Email]";
    String USER_PASSWORD	= "[ Dropbox User Password]";

    WebDriver driver 		= new FirefoxDriver();

    // Load the root page, which contains an authorization link
    driver.get(APP_URL);

    // Find the link and click it
    WebElement element = driver.findElement(By.name("authorize"));
    element.click();

    // Wait for the Email input field to become visible
    WebElement elementEmail = (new WebDriverWait(driver, TIMEOUT))
          .until(ExpectedConditions.elementToBeClickable(By.xpath("//input[@class='text-input-input autofocus']")));

    // Insert the user's email address into the input field
    elementEmail.sendKeys(USER_EMAIL);

    // Wait for the Password input field to become visible
    WebElement elementPassword = (new WebDriverWait(driver, TIMEOUT))
        .until(ExpectedConditions.elementToBeClickable(By.xpath("//input[@class='password-input text-input-input']")));

    // Insert the user's password into the input field
    elementPassword.sendKeys(USER_PASSWORD);

    // Find the "Sign in" button and click it
    WebElement elementSignIn = driver.findElement(By.xpath("//button[@class='login-button button-primary']"));
    elementSignIn.click();

    // Wait for the Allow button to be on the page and clickable, then click the button
    WebElement elementAllow = (new WebDriverWait(driver, TIMEOUT))
          .until(ExpectedConditions.elementToBeClickable(By.xpath("//button[@name='allow_access']")));
    elementAllow.click();


    // Here data returned by /auth can be checked, and either pass or fail this test.


    //Close the browser
    driver.quit();
  }
}


Cuando ejecuta el código, Selenium abre un navegador Firefox y simula las entradas del usuario.

La prueba en sí está automatizada y simula a un usuario sin ningún paso manual, pero aún requiere que alguien haga clic en el botón Ejecutar en Eclipse. Por supuesto, esta parte también se puede automatizar. Jenkins es un servidor de automatización de pruebas que puede ejecutar pruebas programadas, incluidas las pruebas de Selenium WebDriver (requiere un complemento). También puede extraer código de GitHub u otros repositorios SVN, por lo que se puede programar que Jenkins extraiga código de un repositorio todas las noches y ejecute los scripts de prueba.

Observaciones finales

Los cambios en la API pueden interrumpir su aplicación, así que tenga un proceso para estar preparado para los cambios. Las pruebas automatizadas de un extremo a otro pueden validar que la aplicación está funcionando, incluidas las API de terceros. Si algunos cambios de API se escapan, se descubrirán muy pronto con pruebas automatizadas frecuentes (diarias). Las pruebas automatizadas , es decir, el uso de scripts y herramientas de prueba para simular usuarios, ofrecen resultados consistentes y no requieren la interacción del usuario.

El ejemplo anterior muestra cómo probar un flujo de OAuth, lo que puede ser un desafío debido a los redireccionamientos. Debido a que es un desafío, lo encontramos como un ejemplo de caso de uso interesante. En este caso, cuando se utiliza una biblioteca de terceros para manejar la autenticación, la prueba no es solo una prueba de la autenticación, sino también la integración con la biblioteca . Cuando tiene éxito, la aplicación inicia el proceso de autenticación a través de las funciones de la biblioteca y devuelve el token de acceso a la ruta de devolución de llamada de la aplicación. Esto confirma que el flujo desde la aplicación, a través de la biblioteca de terceros, la autenticación y la devolución de llamada a la aplicación nuevamente funciona.

Las pruebas deben cubrir todos los casos de uso y simular todas las posibles acciones del usuario. Esto generalmente incluye, pero no se limita a, operaciones CRUD (Crear, Leer, Actualizar, Eliminar) con verificación de IU. Las pruebas también deben considerar casos de esquina y verificación de errores ; por ejemplo, la prueba regresa cuando se proporcionan credenciales de usuario incorrectas, o si se proporciona una entrada no válida en un campo de entrada y otras operaciones propensas a errores.

En general, asegúrese de que sus pruebas reflejen casos de uso del mundo real. Con las pruebas automatizadas de extremo a extremo, cuando los cambios en la API se produzcan, su equipo será notificado fácilmente y podrá responder en consecuencia.

Publicar un comentario

0 Comentarios