Te va a interesar!

6/recent/ticker-posts

Entendiendo el concepto de API: analogías everywhere!

Resultado de imagen para API

Bienvenidos a un post sobre Automation Testing! En el día de hoy voy a empezar con una sencilla teoría antes de entrar de lleno en automatización de APIs, tanto RESTful como SOAP (si es que todavía existe alguien usando el último).

Pero...qué es una API?

La definición de wikipedia es bastante directa: Application Programming Interface. Pero para dar a entender a alguien que no está muy en tema no me sirve. Les voy a hacer una analogía que una vez vi y me sirvió mucho para entender qué son y qué no son:

Piensen en una API como una UI, solo que apuntada a otro tipo de usuarios. Suena contradictorio, pero les voy a fundamentar.
Una API es una interfaz (de hecho está en la sigla) mediante la cual un software consume datos o servicios de otro software. Básicamente lo mismo que nosotros vemos en la interfaz de usuario, con colores, animaciones, botones lindos y arreglos, solo que completamente pelado.
Los scripts no tienen ojos para apreciar la belleza del renderizado de la página, ni necesita tener una paleta de colores atractiva para consumir los datos que provee la API, solo necesita una respuesta ante su pedido.


La analogía definitiva: El enchufe y la electricidad.

Hoy vengo a full con las analogías y metáforas, así que agárrense. Para pensar en cómo es la dinámica de las API y cómo son consumidas, piensen lo siguiente: Las APIs son tomacorrientes.

Resultado de imagen para enchufe

Si lo piensan, los tomacorrientes son básicamente interfaces a un servicio: la electricidad. Al mismo tiempo este servicio es consumido por una variedad de aparatos en nuestra casa. Desde celulares, a Playstations, computadoras, cafeteras, etc. Entonces, les pido que piensen en la corriente eléctrica suministrada como el servicio y, los aparatos que la consumen, como usuarios.

Salvando las diferencias de región, los tomacorrientes tienen estándares que cumplen y que sabemos de antemano cuando vamos a consumir su servicio. En argentina sabemos que vamos a recibir 220 de AC y que el enchufe tiene que ser de determinada manera. Sabemos que si enchufamos un aparato 220 ahí vamos a tener la corriente necesaria para que funcione (no enchufen un aparato 110 por favor!).

De la misma manera, las API tienen especificaciones sobre cómo las piezas de software van a interactuar. De esa manera los que hacen los aparatos no tienen que pensar en cómo va a funcionar todo el proceso mediante el cual el servicio de la electricidad llega a su aparato, sino simplemente que, ante su pedido, va a recibir exactamente la respuesta especificada.

Como usuarios, a nosotros nos simplifica la vida tener tomacorrientes. Imaginate que tengas que andar agarrando cables pelados para jugar a la Play! Sería una pérdida de tiempo, un peligro y no la mejor decisión a tomar un domingo a la tarde. De la misma manera las APIs facilitan la interacción, dando así tiempo a los usuarios en enfocarse en lo importante.

Esta fue una introducción a las APIs y qué son realmente. El ejemplo del tomacorrientes no es mío, lo leí hace un tiempo y siempre me pareció la mejor manera de explicarlo.

Esto nos deja el terreno preparado para la próxima tanda de tutoriales en el Patreon, ya que vamos a estar viendo la librería Rest Assured y cómo vamos a relacionarla con Cucumber para tener nuestro framework y sus reportes testeando webservices en lugar de una interfaz gráfica. Recuerdan cuando les mencionaba que el foco de un Test Engineer debería ser la capa de servicios en el desarrollo de software? Bueno, una vez terminemos con ese segmento de tutoriales van a ser capaces de automatizar esos casos de prueba!
Resultado de imagen para enchufe
El caso de prueba negativo más peligroso del mundo

The Free Range Tester.

Publicar un comentario

1 Comentarios

  1. Nicely related from API to something everyone uses daily. Good job by explaining it in a simple term!

    ResponderBorrar