Contract Tests: ¿por qué deberías tenerlos en tu proyecto?

contract tests

Episodio 57 – Contract Tests: ¿por qué deberías tenerlos en tu proyecto?

Los contract tests son muy útiles. Ésta es una de las ocasiones en las que es interesante hacer un pacto.

Si quieres saber más sobre testing, échale un vistazo a las entradas sobre Testing y TDD y BDD.

Básicamente los tests de contrato son test unitarios que hacemos desde dos lados de un sistema con una fuente de verdad común.

Un ejemplo sencillo: tenemos una app en la que el backend tiene que enviar una respuesta a los equipos de mobile. Ésta respuesta podría ser representada mediante un fichero *.json.

Lo que el backend se compromete es a entregar en su respuesta el contenido de ese mismo fichero y lo que se comprometen los equipos de mobile (tanto de Android como de iOS), es a saber lidiar con esa respuesta.

Por lo tanto, ese fichero JSON será compartido por ambas plataformas y se podrán hacer tests por ambos lados de manera unitaria.

En el audio te lo explico en un plis plas. ¡Dale al play! 😉

Contract Tests

Transcripción

¡Muy buenas!

Soy Gabi Moreno y te doy la bienvenida al episodio número 57 de Productividad en el Desarrollo Android.

El podcast donde hablamos sobre qué puedes hacer para ser una desarrolladora o desarrolladora Android más eficaz y eficiente. Te contamos técnicas, hábitos, herramientas, conceptos, tips y todo aquello que te va a hacer crecer sí o sí. Porque hay algo que todos tenemos en común y es que el día dura 24 horas. Cómo inviertas o gastes este tiempo es cosa tuya.

Los contract tests son una herramienta muy útil para asegurar mediante tests unitarios que nuestras llamadas al backend devuelvan lo que toca. Hoy voy a hablar de lo que viene a ser una fuente única de verdad para ponerte de acuerdo con tus compañeros de backend. Básicamente, los test de contrato son tests unitarios que hacemos desde dos lados de un sistema con una fuente de verdad común.

Un ejemplo sencillo: tenemos una app en la que el backend tiene que enviar una respuesta a los equipos de móvil. Esta respuesta podría ser representada mediante un fichero JSON. Lo que el backend se compromete es a entregar en su respuesta ese mismo fichero y lo que se comprometen los equipos de móvil, tanto Android como iOS, es a saber lidiar con esa respuesta. Por lo tanto, ese fichero JSON será compartido por ambas plataformas y se podrán hacer tests por ambos lados de manera unitaria.

Si, por ejemplo, quisiéramos hacer directamente unos tests en tuen para comprobar que el backend devuelve lo que toca sería caro, lento y no escalaría nada bien. Si ambas partes se comprometen a cumplir ese contrato, nuestro sistema de integración continua será mucho más eficiente. Sería como una especie de interfaz débil, es decir, algo que se debe de cumplir pero que realmente…

Publicado: 2021-07-19 Actualizado: 2024-06-06