Continuando con el framework Ruby on Rails, ya llego la parte en la que automatizamos tareas y verificamos comportamiento a través del módulo de pruebas de Rails.
Consulta aquí el último commit del proyecto.
1 - Tareas
Hasta ahora he usado rake para operar con la base de datos (rake db:migrate y rake db:rollback) y ver las rutas (rake routes), pero realmente podemos hacer mucho más que eso, ya que rake es una herramienta que maneja tareas y logra automatizar operaciones a través de scripting.
Podemos ver todas operaciones por defecto que nos brinda rails al ejecutar rake -T, pero lo mejor es que podemos crear nuestros propias tareas y estas se encontrarán en la carpeta lib/tasks. Una tarea muy básica luce como el siguiente archivo:
Pero ahora bien podemos crear una tarea o un grupo de tareas y esto lo logramos con los namespaces, es así como tenemos el grupo de tareas de base de datos con db, documentación con docs, pruebas con test, entre otros. Entonces con esto en mente voy a crear un grupo de tareas con el nombre ejemplos_tareas y dentro de el mostraré las funciones básicas de tareas que existen. Para esto voy a usar el comando rails generate task ejemplos_tareas, con esto se creará el archivo ejemplos_tareas.rake dentro de nuestra carpeta de tareas.
Aquí les comparto el archivo modificado con las tareas que hice:
Las tareas funcionan bajo el namespace de ejemplos_tareas. Por ejemplo para llamar a la tarea 1 ejecutas rake ejemplos_tareas:mi_tarea_1.
Ya con esto tenemos la idea de como podemos hacer tareas más complejas como generar reportes, asignar al sistema una actualización de datos cada cierto tiempo, hacer respaldos, entre otros.
Puedes consultar la documentación oficial y este otro tutorial que veo muy interesante por si desean aprender mucho más sobre rake.
2 - Introducción a las pruebas
El archivo principal es test/test_helper.rb, este tiene la capacidad de conectarse con las librerías y fixtures (casos de prueba para un modelo), de forma tal que los otros módulos de prueba lo pueden importar y hacer uso de todas sus funciones. Es por esto que incluyo la instrucción include Devise::TestHelpers dentro de este archivo para notificarle al módulo de pruebas de uso de Devise (librería de manejo de usuarios). Además tengo que modificar el fixture del modelo User para tener instancias de prueba.
A partir de este momento podemos empezar a realizar pruebas a nuestros modelos, controladores, integración, mailers y jobs. Ejecutar una prueba lo logramos con nuestra herramienta rake y podemos usar la tarea que prueba todos controladores con el comando rake test:controllers y obtendremos una salida como esta:
.
Finished tests in 0.006932s, 104.420 tests/s, 104.420 assertions/s.
10 tests, 10 assertions, 0 failures, 0 errors, 0 skips
Lo cual significa que se realizaron 10 pruebas y 10 éxitos, que vienen de las pruebas especificadas en los archivos de la carpeta test/controllers que se crearon automáticamente al haber usado Scaffold. En caso de tener errores y fallas se verán en la primera línea del reporte una o más E y F respectivamente. Revisemos entonces el archivo test/controllers/posts_controller_test.rb.
Notemos primeramente que al declarar una prueba la sintaxis de la función es test "should get index" do esto equivale a def test_should_get_index. Ahora bien dentro de las pruebas notemos que usan las funciones assert, estas se aseguran de que se cumplan una condición para determinar el resultado de la prueba y para esto contamos con una gran cantidad de variantes de la función que pueden consultar en la página oficial de Rails.
En detalle las pruebas anteriormente especificadas significan que se cumpla una propiedad, por ejemplo:
Una buena práctica que podemos adoptar al desarrollar es chequear el estatus de nuestras pruebas con un script antes de subir los cambios al repositorio o colocar en producción el sistema.
Para conocer más sobre el módulo de pruebas puedes consultar la documentación oficial. Existen también herramientas como Capybara que buscan facilitar la realización de pruebas.
Si algo no queda muy claro siempre me pueden escribir a mi correo tonylattke@gmail.com o también pueden dejar comentarios al final de este post y trataré de ayudarles lo antes posible.
Accede al repositorio del proyecto aquí.
Consulta aquí el último commit del proyecto.
1 - Tareas
Hasta ahora he usado rake para operar con la base de datos (rake db:migrate y rake db:rollback) y ver las rutas (rake routes), pero realmente podemos hacer mucho más que eso, ya que rake es una herramienta que maneja tareas y logra automatizar operaciones a través de scripting.
Podemos ver todas operaciones por defecto que nos brinda rails al ejecutar rake -T, pero lo mejor es que podemos crear nuestros propias tareas y estas se encontrarán en la carpeta lib/tasks. Una tarea muy básica luce como el siguiente archivo:
- La primera línea nos permite describir brevemente nuestra tarea (muy útil al consultar rake -T).
- En la segunda línea vemos el nombre de la tarea saludar.
- Dentro de la función lo que vemos es sólo la función puts que imprimirá por consola el mensaje.
Pero ahora bien podemos crear una tarea o un grupo de tareas y esto lo logramos con los namespaces, es así como tenemos el grupo de tareas de base de datos con db, documentación con docs, pruebas con test, entre otros. Entonces con esto en mente voy a crear un grupo de tareas con el nombre ejemplos_tareas y dentro de el mostraré las funciones básicas de tareas que existen. Para esto voy a usar el comando rails generate task ejemplos_tareas, con esto se creará el archivo ejemplos_tareas.rake dentro de nuestra carpeta de tareas.
Aquí les comparto el archivo modificado con las tareas que hice:
Las tareas funcionan bajo el namespace de ejemplos_tareas. Por ejemplo para llamar a la tarea 1 ejecutas rake ejemplos_tareas:mi_tarea_1.
- Tarea 1: Hace uso del parámetro enviroment el cual indica que eres capaz de usar los modelos y funciones que tengas del sistema. Noten la posición de los dos puntos en el nombre de la tarea.
- Tarea 2: En este caso hago uso de otra sintaxis de enunciar tareas y sólo lo muestro para que tengan la idea de la flexibilidad que tiene Ruby en su sintaxis.
- Tarea 3: En esta tarea muestro el paso de parámetros y la forma en la que llamamos a esta tarea es rake ejemplos_tareas:mi_tarea_3[42], donde el parámetro es 42.
- Tarea 4: Hace uso de la función Rake::Task para llamar a otras funciones, la cual permite ejecutar otras tareas dentro de nuestra función.
- Tarea 5: En este caso hago uso de la sintaxis para llamar a otras tareas como requisito de la tarea 5, esto quiere decir que se ejecutará las tareas requisito antes de la tarea 5, por lo que se tendrá como salida:
hola
hola 2
hola 3
- Tarea 6: Aquí hago uso de la variable enviroment para poder acceder al modelo Post y dentro de la función me encargo de imprimir un mensaje con el nombre de un Post seleccionado al azar.
Ya con esto tenemos la idea de como podemos hacer tareas más complejas como generar reportes, asignar al sistema una actualización de datos cada cierto tiempo, hacer respaldos, entre otros.
Puedes consultar la documentación oficial y este otro tutorial que veo muy interesante por si desean aprender mucho más sobre rake.
2 - Introducción a las pruebas
El archivo principal es test/test_helper.rb, este tiene la capacidad de conectarse con las librerías y fixtures (casos de prueba para un modelo), de forma tal que los otros módulos de prueba lo pueden importar y hacer uso de todas sus funciones. Es por esto que incluyo la instrucción include Devise::TestHelpers dentro de este archivo para notificarle al módulo de pruebas de uso de Devise (librería de manejo de usuarios). Además tengo que modificar el fixture del modelo User para tener instancias de prueba.
A partir de este momento podemos empezar a realizar pruebas a nuestros modelos, controladores, integración, mailers y jobs. Ejecutar una prueba lo logramos con nuestra herramienta rake y podemos usar la tarea que prueba todos controladores con el comando rake test:controllers y obtendremos una salida como esta:
.
Finished tests in 0.006932s, 104.420 tests/s, 104.420 assertions/s.
10 tests, 10 assertions, 0 failures, 0 errors, 0 skips
Lo cual significa que se realizaron 10 pruebas y 10 éxitos, que vienen de las pruebas especificadas en los archivos de la carpeta test/controllers que se crearon automáticamente al haber usado Scaffold. En caso de tener errores y fallas se verán en la primera línea del reporte una o más E y F respectivamente. Revisemos entonces el archivo test/controllers/posts_controller_test.rb.
Notemos primeramente que al declarar una prueba la sintaxis de la función es test "should get index" do esto equivale a def test_should_get_index. Ahora bien dentro de las pruebas notemos que usan las funciones assert, estas se aseguran de que se cumplan una condición para determinar el resultado de la prueba y para esto contamos con una gran cantidad de variantes de la función que pueden consultar en la página oficial de Rails.
En detalle las pruebas anteriormente especificadas significan que se cumpla una propiedad, por ejemplo:
- should get index: Busca obtener el listado de Post, compara con el valor de éxito y chequea que se instancie la variable posts.
- should get new: Crea una instancia del modelo Post y compara con el valor de éxito.
- should create post: Verifica que si sea creado el Post, tomando el número de instancias del antes y después. La prueba finaliza con asegurarse del redireccionamiento a la muestra del Post.
- should show post y should get edit: Buscan asegurarse que se tome Post según el id.
- should update post: Se verifica la actualización del Post. La prueba finaliza con asegurarse del redireccionamiento a la muestra del Post.
- should destroy post: Se verifica que el Post sea eliminado, comparando el número de instancias del antes y después.
Una buena práctica que podemos adoptar al desarrollar es chequear el estatus de nuestras pruebas con un script antes de subir los cambios al repositorio o colocar en producción el sistema.
Para conocer más sobre el módulo de pruebas puedes consultar la documentación oficial. Existen también herramientas como Capybara que buscan facilitar la realización de pruebas.
Si algo no queda muy claro siempre me pueden escribir a mi correo tonylattke@gmail.com o también pueden dejar comentarios al final de este post y trataré de ayudarles lo antes posible.
Accede al repositorio del proyecto aquí.
