5 Reglas para desacoplar tu aplicación de Rails y tener pruebas realmente rápidas
En los últimos proyectos que he trabajado, tanto solo como en equipo, poco a poco he ido descubriendo ciertas practicas o reglas que usamos y que quiero compartir porque creo que también te pueden servir.
Estas practicas nos han ayudado a:
- Tener pruebas rápidas (algo así como 1000 pruebas en 2seg)
- Saber que el sistema funciona todo el tiempo (por lo menos lo que has probado)
- Poder hacer cambios más rápido.
- Tener más claras las reglas de negocio
- Borrar código sin remordimientos
Nota: Cuando digo pruebas rápidas me refiero más o menos a esto…
Las reglas que seguimos son…
1. La lógica de tu aplicación o lógica de “negocio” va detrás de métodos o funciones de módulo.
No es necesario hacer mucha “ceremonia” y hablar de “Interactors”, “Service Objects”, “Presenters” o algún otro patrón.
Aunque probablemente usarás algo similar a estas cosas ya dependerá de tu aplicación.
Un ejemplo de las funciones que podría tener un módulo sería algo así:
2. Estas funciones de módulo las llamas dentro de de Rails, es decir de tu controlador/mailer/job/model/etc.
Algo importante aquí es que las funciones sean de primer nivel es decir que no usemos funciones con doble namespace como Projects::TerminateFunding.form.
Tal vez en tu aplicación habrá casos donde ocupes hacer este namespace, pero a mi no me ha tocado.
Un ejemplo podría ser así:
3. En estos módulos no puedes tener ninguna dependencia directa de ninguna clase de Rails.
En esta regla, se vale incluir librerías como ActiveModel o ActiveSupport, pero es mejor ser prudente.
En general todas las dependencias son “inyectadas” como parámetros de la función.
El anterior ejemplo muestra una forma de hacerlo, pero aquí muestro un ejemplo más:
4. Todas las pruebas son a través de las funciones de módulo.
Es decir que vamos a probar justo a través de las funciones que vamos a llamar desde los componentes de Rails.
Por lo que no hay pruebas para clases internas o métodos privados. ¡Esto es lo que nos permitirá refactorizar!
En algunos casos, tendrás que ingeniártelas para hacer que las pruebas sean claras o específicas, como en el siguiente ejemplo:
5. No usar active record en las pruebas.
Esto es hace que tus pruebas corran mucho más rápido porque no necesitas cargar Rails y hacer cada operación en la base de datos.
Y también te ayuda a modelar mejor la interfaz entre tu sistema y active record porque podrás trabajar el diseño por medio de las pruebas antes de crear tablas en la base de datos.
Yo tiendo a hacer esto por medio de simples objetos de ruby como en el siguiente ejemplo:
¡Y listo!… ¡Espero que a ti también te sean de utilidad!
