Implementar pruebas de sistema en una aplicación Rails permite verificar que la interfaz gráfica funcione correctamente desde la perspectiva del usuario. Usando Capybara junto con Selenium WebDriver, es posible simular interacciones reales con formularios, botones y elementos de selección, todo dentro del flujo de testing automatizado con RSpec.
¿Cómo generar la estructura de una prueba de sistema en Rails?
El primer paso consiste en utilizar el generador de Rails desde la consola de comandos [00:16]. El comando es:
bash
rails generate rspec:system task
Este comando crea un archivo dentro de la carpeta system, con una estructura base lista para escribir las pruebas. Al abrir el archivo generado, se encuentra una taxonomía inicial con un bloque pending que conviene eliminar, y un bloque before que se mantiene para configurar el estado previo a cada prueba [00:48].
¿Qué es el DSL de Capybara y cómo se usa para visitar páginas?
Capybara ofrece un DSL (Domain Specific Language) que proporciona métodos para simular la interacción del usuario con el navegador. Puedes consultar toda la documentación en el repositorio oficial de GitHub bajo teamcapybara/capybara [02:00].
La primera prueba diseñada busca verificar que la página de tareas contenga el título correcto [01:10]:
ruby
describe "GET /tasks" do
it "has a correct title" do
visit "/tasks"
expect(page).to have_content("Lista de tareas")
end
end
- visit: permite acceder a una ruta específica dentro de la aplicación.
- have_content: valida que el texto esperado esté presente en la página renderizada.
¿Por qué aparece un error de driver al ejecutar las pruebas?
Al correr rspec por primera vez, el sistema indica que no se encontró un driver apropiado [03:05]. Las pruebas de sistema necesitan un WebDriver que controle un navegador real o headless. La solución es agregar la gema selenium-webdriver en el grupo de test del Gemfile:
ruby
group :test do
gem 'selenium-webdriver'
end
Después de instalar la gema con bundle install, las pruebas pueden comunicarse con un navegador de prueba para renderizar las páginas [03:30].
¿Cómo resolver el problema de autenticación en pruebas de sistema?
Tras instalar el WebDriver, surge un segundo error relacionado con la autenticación [04:05]. Similar a lo que ocurre con las pruebas de petición (request specs), es necesario configurar los Integration Helpers de Devise dentro del archivo rails_helper.rb, pero esta vez para pruebas de tipo system.
En el bloque before, se crea un usuario y se inicia sesión con el helper sign_in [04:30]:
ruby
before do
user = create(:user)
sign_in user
end
Con esta configuración, la prueba corre exitosamente y valida el contenido de la página [05:00].
¿Cómo interactuar con formularios usando Capybara?
Para verificar la creación de una tarea, se visita la ruta /tasks/new y se interactúa con los elementos del formulario [05:30]. Capybara ofrece métodos específicos según el tipo de elemento HTML.
¿Cuál es la diferencia entre fill_in y select en Capybara?
fill_in se usa para campos de texto como inputs y textareas. En lugar de referenciarse por el label, se recomienda usar el atributo name del HTML para mayor precisión [06:20]:
ruby
fill_in "task[name]", with: "test dos"
fill_in "task[description]", with: "mi descripción"
fill_in "task[due_date]", with: 1.day.from_now.strftime("%Y-%m-%d")
select se utiliza para elementos <select>. Recibe la opción visible y el parámetro from con el nombre del campo [07:35]:
ruby
select category.name, from: "task[category_id]"
¿Qué hace let! con bang y por qué es necesario aquí?
La categoría debe existir antes de que se renderice la página, para que aparezca en la lista desplegable. Usar let! (con bang) garantiza que el registro se cree inmediatamente al iniciar la prueba, sin esperar a que sea invocado en el código [08:15]. Con let convencional, la fábrica solo se ejecuta cuando se referencia por primera vez, lo cual es demasiado tarde si la página ya se cargó.
ruby
let!(:category) { create(:category) }
Hasta este punto se han resuelto dos problemas fundamentales: la integración del WebDriver y la configuración de autenticación. La implementación contiene un error intencional que debes encontrar al ejecutar las pruebas. ¿Pudiste identificarlo y corregirlo? Comparte tu solución en los comentarios.
