Preparar un proyecto Rails para recibir pruebas automatizadas requiere instalar y configurar varias gemas que trabajan en conjunto. Desde el manejo de la base de datos hasta la generación de datos falsos, cada librería cumple un rol específico que garantiza pruebas confiables, independientes y expresivas. A continuación se detalla todo el proceso paso a paso.
¿Qué gemas se necesitan en el grupo de pruebas?
El punto de partida es el Gemfile, el archivo de gestión de gemas del proyecto. Se recomienda crear un grupo exclusivo para el escenario de development y test, en lugar de mezclar gemas con otros ambientes [0:28].
Dentro de este grupo se instalan tres gemas fundamentales:
- Database Cleaner: controla el estado de la base de datos entre pruebas. En MongoDB no se utilizan sistemas transaccionales tradicionales como rollbacks o commits, por lo que esta gema se encarga de limpiar los registros después de cada prueba para que se ejecuten de forma independiente [1:10].
- Faker: genera información falsa de manera automática, como nombres, correos e incluso pokémons, sin necesidad de inventar datos manualmente [1:56].
- Capybara: permite realizar pruebas de interacción gráfica con el navegador. Aunque no se usa de inmediato, es necesario dejarlo configurado desde el inicio [2:14].
Además de estas tres, se añaden dos gemas en el grupo compartido entre desarrollo y pruebas:
- RSpec Rails: la versión de RSpec integrada con Rails, ya que RSpec por sí solo no está ligado directamente al framework [2:50].
- Factory Bot Rails: permite crear fábricas automáticas de instancias de modelos como categorías, participantes, tareas y usuarios [3:06].
Una vez modificado el Gemfile, se ejecuta bundle install en la terminal para instalar todas las dependencias [3:38].
¿Cómo se generan y editan los archivos de configuración de RSpec?
RSpec ofrece un generador que crea los archivos base de configuración. Al ejecutar el comando del generador rspec:install, se crean dos archivos clave: spec_helper y rails_helper [3:50].
¿Qué configurar en el spec helper?
En el archivo spec_helper hay dos líneas importantes que se deben habilitar [4:17]:
filter_run_when_matching :focus permite ejecutar únicamente una prueba específica cuando el número de pruebas es considerable, evitando correr toda la suite [4:28].default_formatter "doc" cambia el formato de salida en consola para que los resultados sean más expresivos y detallados [4:58].
¿Qué configurar en el rails helper?
El archivo rails_helper requiere mayor trabajo. Primero se importan las librerías instaladas: factory_bot_rails, database_cleaner y capybara/rails [5:30].
Luego se establecen varias configuraciones esenciales:
- Desactivar transacciones: como MongoDB no las maneja de la misma forma, se coloca
use_transactional_fixtures en false [6:06].
- Incluir helpers de Factory Bot: se usa la sintaxis CamelCase (
FactoryBot::Syntax::Methods) para que los métodos de creación de fábricas estén disponibles en las pruebas [6:22].
- Incluir helpers de Warden y Devise: la librería Warden, que Device utiliza internamente para el inicio de sesión, también necesita sus helpers configurados para pruebas de autenticación [6:58].
¿Cómo funciona Database Cleaner con Mongoid?
La configuración de Database Cleaner se realiza mediante callbacks dentro del bloque de configuración de RSpec [7:26].
El callback before(:suite) se ejecuta una sola vez antes de todo el grupo de pruebas. Aquí se establece que el ORM utilizado es Mongoid en lugar de Active Record, y se hace una limpieza inicial de la base de datos [7:40].
Para las pruebas individuales se usan dos callbacks adicionales:
before(:each) inicializa Database Cleaner antes de cada prueba.after(:each) ejecuta clean para limpiar la base de datos al finalizar cada escenario [8:22].
Finalmente, se habilita el módulo de Devise específicamente para pruebas de controlador mediante config.include Devise::Test::ControllerHelpers [8:52]. La opción infer_spec_type_from_file_location permite que RSpec detecte automáticamente el tipo de prueba según el nombre del directorio, asignando los métodos correspondientes a pruebas de modelo, controlador, peticiones o sistema [9:16]. Por otro lado, filter_rails_from_backtrace oculta las líneas de error pertenecientes al core de Rails para mostrar solo lo relevante a tu código [9:48].
Con toda esta configuración lista, el siguiente paso natural es crear las fábricas de modelo con Factory Bot para después escribir las pruebas asociadas a cada modelo. ¿Ya tienes claro cuáles serán tus primeras fábricas? Comparte tu experiencia configurando el entorno.
