Luis Eduardo Cuevas Rivero
El error esta en la linea 25 del spec
5.day
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
¿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.
Luis Eduardo Cuevas Rivero
El error esta en la linea 25 del spec
5.day
Carlos Alfonso Garcia Gonzales
Explicación de let! (porque se usa el caracter !)
Sebastian Kloster
Cuando ejecuto las pruebas estoy creando un nuevo user con let y usando la factory. Este nuevo User queda persistido en la base de datos? Podria esto ser un problema?
Johan Tique
ProfesorHola Sebastián, cuando usamos pruebas automatizadas podemos hacer uso de escenarios persitidos o no persistidos, para escenarios persistidos ten en cuenta que nuestra base de datos, es una base de datos de pruebas (que es una BD común y corriente) pero con la característica de que es limpiada en cada escenario (it) y en cada suite (suite) de pruebas conservando su aislamiento como fue mencionado en la clase 8 Esteroides para tus pruebas, para este caso estamos usando la estrategia proveida por el DatabaseCleaner (para BD relacionales podemos usar estrategias transaccionales para lograr esto aunque debemos tener cuidado)
En esencia con el DatabaseCleaner y una configuración un poco más avanzada de Threads podemos correr las pruebas de forma paralela y no habría ningún problema, porque en Rspec se debe respetar que todas las pruebas sean independientes entre unas y otras.