1. Introducción

Ruby on Rails y las pruebas automatizadas van de la mano. Rails incluye un framework de pruebas integrado. Cuando usas los generadores, crea automáticamente archivos de prueba base listos para que los rellenes con tus propias pruebas. Eso es bastante genial, si me preguntas.

Sin embargo, muchas personas que desarrollan en Rails todavía no prueban sus proyectos en absoluto, o en el mejor de los casos, solo añaden unas pocas specs simbólicas sobre cosas básicas que puede que ni siquiera sean útiles ni informativas. Quizás trabajar con Ruby o con frameworks web dogmáticos ya es un concepto suficientemente novedoso, y añadir una capa extra de trabajo parece exactamente eso: ¡trabajo extra! O tal vez hay una sensación de falta de tiempo — dedicar tiempo a escribir pruebas se lo quita a escribir las funcionalidades que nuestros clientes o jefes exigen. O quizás el hábito de definir probar como la práctica de hacer clic en enlaces en el navegador es simplemente demasiado difícil de romper.

Yo he estado ahí. Como ingeniero, tengo problemas que resolver. Y, por lo general, encuentro soluciones a esos problemas construyendo software. Llevo desarrollando aplicaciones web desde 1995. Durante mucho tiempo, trabajé como desarrollador en solitario en proyectos del sector público con presupuesto mínimo. Salvo una exposición estructurada a BASIC de niño, algo de C++ en la universidad y una semana perdida de formación en Java en mi segundo trabajo de adulto fuera de la universidad, nunca tuve una educación formal de verdad en desarrollo de software. De hecho, no fue hasta 2005, cuando ya había tenido suficiente de hackear código PHP feo al estilo espagueti, que busqué una mejor manera de escribir aplicaciones web.

Había mirado Ruby antes, pero nunca le había encontrado un uso serio hasta que Rails empezó a cobrar fuerza. Había mucho que aprender — un nuevo lenguaje, una arquitectura real y un enfoque más orientado a objetos. Aun con todos esos nuevos desafíos, era capaz de crear aplicaciones complejas en una fracción del tiempo que me llevaba con mis esfuerzos anteriores sin framework. ¡Estaba enganchado!

Pruebas con confianza

Pero los primeros libros y tutoriales de Rails se centraban más en la velocidad de desarrollo (¡construye un blog en 15 minutos!) que en buenas prácticas como las pruebas. Si las trataban, por lo general las reservaban para un capítulo hacia el final. Los recursos educativos más recientes sobre Rails han abordado esta carencia y demuestran cómo probar aplicaciones desde el principio. Hoy existen innumerables libros específicamente sobre el tema de las pruebas. Pero sin un enfoque sólido hacia el lado de las pruebas, muchos desarrolladores — especialmente aquellos en una situación similar a la que yo estaba — pueden encontrarse sin una estrategia de pruebas coherente. Si es que hay pruebas, puede que no sean fiables ni significativas. Ese tipo de pruebas no generan confianza del desarrollador.

Mi primer objetivo con este libro es presentarte una estrategia coherente que funciona para — una que tú puedas, con suerte, adaptar para que también funcione de forma coherente para ti. Si lo logro, al leer este libro probarás con confianza. Podrás hacer cambios en tu código sabiendo que tu suite de pruebas te cubre las espaldas y te avisará si algo se rompe.

¿Por qué RSpec?

No tengo nada en contra de otros frameworks de pruebas de Ruby. Si el framework MiniTest predeterminado te ayuda a escribir suites de pruebas sostenibles con confianza, ¡genial!

Para mí, la capacidad de RSpec para producir specs que son legibles sin resultar excesivamente engorrosas es lo que me convence. Hablaré más sobre esto más adelante en el libro, pero he descubierto que con un poco de orientación, incluso la mayoría de las personas no técnicas pueden leer una spec escrita en RSpec y entender qué está pasando. Es tan expresivo que usar RSpec para describir cómo espero que se comporte mi software se ha convertido en algo completamente natural. La sintaxis fluye de mis dedos y es agradable de leer en el futuro cuando estoy haciendo cambios en mi software.

Mi segundo objetivo con este libro es ayudarte a sentirte cómodo con la funcionalidad y la sintaxis de RSpec que es más probable que uses de forma habitual. RSpec es un framework complejo, pero como muchos sistemas complejos, a menudo te encontrarás usando el 20 por ciento de la funcionalidad disponible para el 80 por ciento de tu trabajo. Con eso en mente, esta no es una guía completa de RSpec ni de librerías complementarias como Capybara. En cambio, se centra en las herramientas que he usado durante años para probar mis propias aplicaciones Rails. También te presentará patrones comunes para que, cuando te encuentres con un problema que no está cubierto en el libro, puedas buscar soluciones de forma inteligente y no te quedes atascado.

Quién debería leer este libro

Si Rails es tu primera incursión en un framework de aplicaciones full-stack y tu experiencia de programación anterior no incluía pruebas de ningún tipo, este libro te ayudará, con suerte, a empezar. Si eres muy nuevo en Rails, puede que te resulte beneficioso revisar material sobre desarrollo y pruebas básicas. Mi favorito es Agile Web Development with Rails 8 de Sam Ruby; a mucha gente también le gusta el Rails Tutorial de Michael Hartl. Mi libro asume que ya tienes algunas habilidades básicas de Rails a tus espaldas. En otras palabras, no te enseñará a usar Rails ni te proporcionará una introducción desde cero a las herramientas de prueba integradas en el framework. En cambio, vamos a instalar RSpec y algunos extras para que el proceso de pruebas sea lo más fácil posible de entender y gestionar. Así que si eres nuevo en Rails, echa un vistazo a uno de esos recursos primero y luego vuelve a este libro.

Si llevas un tiempo desarrollando en Rails pero las pruebas siguen siendo un concepto ajeno para ti, ¡este libro es para ti! Yo estuve en tu misma posición durante mucho tiempo, y las técnicas que compartiré aquí me ayudaron a mejorar mi cobertura de pruebas y a pensar más como un desarrollador guiado por pruebas. Espero que hagan lo mismo por ti.

En concreto, deberías tener un buen manejo de:

  • Las convenciones de las aplicaciones Model-View-Controller del lado del servidor, tal como se usan en Rails
  • Bundler para la gestión de dependencias de gems
  • Cómo trabajar con la línea de comandos de Rails

Si ya estás familiarizado con MiniTest, o incluso con RSpec, y ya tienes un flujo de trabajo consolidado que te da confianza, puede que puedas ajustar algunos aspectos de tu enfoque para probar tus aplicaciones. Espero que también aprendas de mi enfoque con criterio propio sobre las pruebas, y de cómo pasar de simplemente probar tu código a hacerlo con intención.

Este no es un libro sobre teoría general de pruebas, y tampoco profundiza demasiado en los problemas de mantenimiento y rendimiento que pueden ir acumulándose en el software heredado con el tiempo. Otros libros pueden ser más útiles en esos temas.

Mi filosofía sobre las pruebas

¿Qué tipo de pruebas es mejor: las unitarias o las de integración? ¿Debería practicar el desarrollo guiado por pruebas o el desarrollo guiado por comportamiento (y cuál es la diferencia, de todas formas)? ¿Debería escribir mis pruebas antes de escribir el código, o después? ¿O debería siquiera molestarme en escribir pruebas?

Debatir sobre la forma correcta de probar tu aplicación Rails puede desatar encendidas disputas entre programadores. Sí, existe una forma correcta de hacer pruebas, pero en mi opinión, hay distintos grados de correcto cuando se trata de este tema. Mi enfoque se basa en las siguientes creencias fundamentales:

  • Las pruebas deben ser confiables.
  • Las pruebas deben ser fáciles de escribir.
  • Las pruebas deben ser fáciles de entender: hoy y en el futuro; por ti y por tus colaboradores.

En resumen: las pruebas deben darte confianza como desarrollador de software. Si tienes en cuenta estos tres factores en tu enfoque, estarás muy bien encaminado hacia una suite de pruebas sólida para tu aplicación, sin mencionar que te convertirás en un auténtico practicante del Desarrollo Guiado por Pruebas.

Sí, hay algunas concesiones; en particular:

  • No nos estamos enfocando en la velocidad, aunque hablaremos de ello más adelante.
  • No nos estamos enfocando en un código excesivamente DRY en nuestras pruebas. Pero en las pruebas, eso no es necesariamente algo malo. También hablaremos de esto.

Al final, sin embargo, lo más importante es que tendrás buenas pruebas, y las pruebas confiables y comprensibles son una excelente manera de empezar, aunque no estén tan optimizadas como podrían estarlo. Este es el enfoque que finalmente me ayudó a superar el obstáculo entre escribir mucho código de aplicación, llamar “pruebas” a una ronda de clics en el navegador, subir a producción y esperar lo mejor. Hay una forma mejor: aprovechar una suite de pruebas completamente automatizada y usar las pruebas para guiar el desarrollo y rastrear posibles errores y casos límite antes de que los usuarios los encuentren.

Y ese es el enfoque que adoptaremos en este libro.

Cómo está organizado el libro

En Testing Rails with RSpec te guiaré a través del proceso de llevar una aplicación básica de Rails de no tener ninguna prueba a tener una cobertura respetable con RSpec. El libro cubre Rails 8.1 y RSpec 3.13 (a través de rspec-rails 8.0). Muchos de los conceptos se aplican a versiones anteriores y posteriores de cada uno, aunque con una sintaxis ligeramente diferente.

El libro comienza con la instalación de RSpec en una aplicación Rails existente. A partir de ahí, construimos una suite de pruebas poco a poco, comenzando con pruebas pequeñas y aisladas y avanzando hacia escenarios de prueba más amplios y complejos. Este es el mismo proceso paso a paso que usé para mejorar en las pruebas de mi propio software. Te recomiendo encarecidamente trabajar en los ejercicios dentro de tus propias aplicaciones: una cosa es seguir un tutorial, y otra muy distinta es aplicar lo que aprendes a tu propia situación. En este libro no construiremos una aplicación juntos, sino que exploraremos patrones y técnicas de código. ¡Toma esas técnicas y mejora tus propios proyectos!

Descarga del código de ejemplo

Puedes obtener el código de ejemplo en https://leftofthe.dev/rspecbook. El archivo Zip proporcionado contiene instantáneas de la aplicación de ejemplo y su suite de pruebas a medida que crece, capítulo a capítulo. Por ejemplo, el directorio 02-models incluye la propia aplicación Rails y las pruebas añadidas en el capítulo 2.

Convenciones de código

Estoy usando la siguiente configuración para esta aplicación:

  • Rails 8.1: La versión más reciente de Rails es el principal foco de este libro. Que yo sepa, la mayoría de las técnicas que utilizo se aplicarán a cualquier versión de Rails desde la 7.2 en adelante. Es posible que algunos ejemplos de código no funcionen exactamente igual en tu caso, pero haré todo lo posible por indicarte dónde podrían existir diferencias.
  • Ruby 4.0: Cualquier versión de Ruby 4 debería funcionar. Ruby 3.2 o superior es el mínimo requerido por rspec-rails 8.0.
  • RSpec 3.13 (rspec-rails 8.0): RSpec 3.0 fue lanzado en la primavera de 2014 y ha permanecido bastante estable desde entonces. La gem rspec-rails ahora sigue el versionado de Rails (de ahí el salto de la versión 6.x a la 8.x). Las versiones anteriores usaban una sintaxis significativamente diferente que no cubriremos en esta edición del libro.

Si algo es específico de estas versiones, haré todo lo posible por señalarlo. Si estás trabajando con una versión más antigua de Rails, RSpec o Ruby, las versiones anteriores del libro están disponibles como descargas gratuitas a través de Leanpub al adquirir esta edición. No son idénticas en cuanto a funcionalidades, pero con suerte deberías poder ver algunas de las diferencias básicas.

De nuevo, ¡este libro no es un tutorial tradicional! El código que se incluye aquí no pretende guiarte en la construcción de una aplicación. Está aquí para ayudarte a entender y aprender patrones y hábitos de pruebas para aplicar a tus propias aplicaciones Rails. En otras palabras, puedes copiar y pegar, pero probablemente no te sirva de mucho a largo plazo.

Discusión y erratas

He dedicado mucho tiempo y esfuerzo a asegurarme de que Testing Rails with RSpec sea lo más libre de errores posible, pero puede que encuentres algo que se me haya pasado por alto. Si ese es el caso, dirígete a la sección de issues del código fuente en GitHub para compartir un error o pedir más detalles: https://github.com/everydayrails/rspec-sample-rails-8.1/issues

Una nota sobre las versiones de gemas

Las versiones de gemas utilizadas en este libro y en la aplicación de ejemplo son las actuales en el momento en que escribo esta edición de Rails 8.1, en 2026. Por supuesto, cualquiera de ellas puede actualizarse con frecuencia, así que estate atento a ellas en Rubygems.org, GitHub y tus fuentes de noticias favoritas sobre Ruby.

Una nota sobre el estilo

Muchos de los ejemplos de código incluidos en este libro están basados en código creado por generadores. Como resultado, es posible que veas ejemplos con estilos inconsistentes — por ejemplo, el uso de comillas simples y dobles en el mismo archivo. Con el fin de preservar las diferencias entre lo que se genera y lo que importa para aprender RSpec, he optado por dejar los estilos del código generado tal como están, pero en general seguiré las convenciones definidas por Standard Ruby.

Sobre la aplicación de ejemplo

¡Conoce TasteDrivenDishes, el último sitio social para encontrar y compartir tus recetas favoritas con usuarios de todo el mundo! Será mejor que tengamos una suite de pruebas en marcha antes de que el sitio llegue a la portada de Hacker News — es mejor que seamos nosotros quienes los detectemos (y corrijamos) antes que nuestros usuarios e inversores.

Para empezar, TasteDrivenDishes incluye las siguientes funcionalidades:

  • Un usuario puede explorar recetas y filtrar por categoría.
  • Un usuario puede crear una cuenta para añadir sus propias recetas.
  • Un usuario con sesión iniciada puede marcar recetas como favoritas.
  • La cuenta de un usuario tiene un avatar, proporcionado por el servicio Dicebear.
  • Un desarrollador puede acceder a una API pública para desarrollar aplicaciones cliente externas.

Hasta este punto, he evitado intencionadamente escribir pruebas para la aplicación (consulta la carpeta 01-untested en la descarga del código de ejemplo). Esto significa que tengo un directorio test lleno de archivos de prueba intactos y preparación de datos. Podría ejecutar bin/rails test, y quizás algunas de estas pruebas incluso pasarían. Pero como este es un libro sobre RSpec, eliminaremos esta carpeta, configuraremos Rails para usar RSpec en su lugar, y construiremos una suite de pruebas fiable. Eso es lo que abordaremos en este libro.

Lo primero es lo primero: necesitamos configurar la aplicación para que reconozca y use RSpec. ¡Empecemos!