Testing necesario y suficiente

Carlos Vergara
Sep 5, 2018 · 4 min read

Desarrollo guiado por comportamiento en React

En el desarrollo de una aplicación mediana-grande rutinariamente se producen grandes cantidades de especificaciones más o menos formales, las cuales usamos como guía para desarrollar una pieza u otra; típicamente bajo la forma de una tarea o ticket en el sistema de trackeo que sea que estemos utilizando (JIRA. Trello, Redmine, etcétera).

Es muy común que esa especificación cambie a lo largo de la vida del proyecto, provocando una cascada de cambios por toda la aplicación para adaptarla al nuevo comportamiento, potencialmente dejando cicatrices, pedazos de código sin demasiado propósito en sus alrededores, y ocasionalmente artefactos como guías de estilo completamente inaplicables a la situación post-cambio.

Existe una metodología formal para tratar con estas situaciones, que es posible implementar hoy con herramientas standard que y que provee una cierta garantía de que en la medida en la que los requerimientos cambien. Esa metodología es el desarrollo guiado por comportamiento.

Desarrollo guiado por Comportamiento (BDD)

Esta manera de encarar el proceso de desarrollo parte de una especificación, o spec, que es fundamentalmente un contrato. Debe ser construida usando un vocabulario particular, porque esta se comparte con el código que vamos a escribir para asegurar que un componente o proceso efectivamente cumple con esta especificación (explico un poco más acerca de este formato en la parte de Features). Estos features en general son escritos directamente por los analistas de negocios, aunque también pueden ser formalizados por los propios programadores, basándose en la especificación informal presentada ante ellos.

La spec está conformada por una serie de features y escenarios, que definen de la manera más llana posible exactamente qué es lo que tiene que ocurrir cuando otra cosa relacionada suceda.

Al cambiar la spec, si el código que la soporta no está actualizado, el test rompe, y por ende el build también, previniendo que cambios a medias terminen en el producto y obligando a reflexionar detenidamente sobre la mejor manera de implementar estos cambios, entonces garantizando un desarrollo un poco más limpio dentro de los límites de la velocidad impuesta por el proyecto.

Este proceso se repite continuamente, hasta que la especificación y el componente se encuentran alineados, manteniendo así al producto coherente consigo mismo todo a lo largo del desarrollo.

Tooling

Para poder trabajar con esta metodología vamos a estar utilizando jest-cucumber, un adaptador para Jest del framework más conocido de BDD, junto con react-test-renderer.

cucumber-js nos provee de algunas primitivas importantes para poder trabajar con features, así como una herramienta de línea de comando para poder correr los tests así generados; TestUtils nos va a permitir probar nuestro componente en aislamiento, y podríamos utilizar una librería como sinon para validar que efectivamente los callbacks que requiera nuestro componente sean utilizados de la manera en la que esperamos.

En nuestro proyecto bastaría con correr:

npm install — save-dev — save-exact react-test-renderer jest-cucumber

Para poder obtener todas las herramientas que necesitamos

Qué es un Feature?

Un feature, literalmente, es una capacidad de tu aplicación. Guardar, Abrir, Editar, son features de tu aplicación. Mover un auto, dar de baja un producto, abrir una galería, también.

En nuestro ejemplo vamos a construir un una galería de fotos sencilla, un componente llamado Gallery, que contendrá Albums, que a su vez contendrán fotos. Queremos que al clickear en esas fotos se las pueda ver en su tamaño “real”.

Estos features se tienen que escribir en archivos con una sintaxis especial, que es brevemente la siguiente:

Manteniendo este vocabulario (que es un lenguaje formal llamado Gherkin) , es posible hacer que el feature tenga tanto detalle como sea necesario, e incluso añadir algo de información de prueba directamente en el feature a través de Scenario Outlines.

Recomiendo ver la documentación de Gherkin para aprender exactamente cómo hacer este tipo de tests, que pueden potencialmente proveer de muchísimo más valor al producto final sólo por estar ahí.

Antes de continuar podemos hacer algunos más, para garantizarnos que nuestro Gallery quede adecuadamente descripto en su totalidad:

Así nuestra aplicación queda completamente descripta por nuestros features.

Y cómo se prueba esto?

Teniendo ya preparados los features y apropiadamente instalado jest-cucumber, es cuestión de empezar a crear steps. Estos son en Cucumber los scripts efectivamente encargados de testear la validez del feature.

En este artículo solo voy a mencionar el primero, pero en el repositorio pueden ver todos los demás.

Primero tendríamos que crear una versión muy básica de los componentes, para no asustar a webpack.

Algo así como:

Es más que suficiente.

Gracias a jest-cucumber, podemos cargar el primer feature y definir formalmente nuestros pasos así:

Desarrollando sobre features

Si recién empezamos, este test va a fallar. Eso está bien, porque el componente no existe en realidad (solo el esqueleto!) Ahora podemos desarrollar el feature!

Por empezar, nuestra galería debiera mostrar Albums. Para eso, reemplazamos el componente anterior por este:

Y nuestro álbum por este:

Así satisfaciendo nuestro primer feature! Debiéramos ver en la consola algo como lo siguiente:

Cuando este feature cambie, este test fallará, permitiéndonos la oportunidad de modificar la estructura de la aplicación como sea necesario.

Este primer feature, así como está, da pie a realizar todos los cambios estructurales que sean necesarios luego, en la medida en la que este cambio esté plasmado en Gherkin en algún lugar del proyecto.

… Profit!

En conclusión, trabajando de este modo es posible entablar una conversación fluida entre quienes forman los requerimientos, quienes los implementan, y quienes regulan el desarrollo del proyecto, permitiendo en última instancia un mejor flujo de trabajo y por ende un producto más sólido.

Ahora, esta es una introducción muy básica; un primer paso para profundizar los tests sería introducir sinon.js y React.TestUtils para permitir checkear la correcta llamada de handlers, callbacks, estado de formularios, etc.

Happy hacking!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade