Testing en Rails

Search…
Testing en Rails
Por defecto Ruby on Rails utiliza Minitest para crear pruebas automatizadas.
En la carpeta test de cada proyecto encontrarás las siguientes carpetas y archivos:
controllers - contiene las pruebas para los controladores.
fixtures - define los datos iniciales para las pruebas.
helpers - contiene las pruebas para los helpers.
integration - contiene las pruebas de integración.
mailers - contiene las pruebas de emails.
models - contiene las pruebas de modelos.
test_helper.rb - la configuración de Minitest.
Ambiente de testing
Rails trae tres ambientes, cada uno con su base de datos independiente y su archivo de configuración independiente: development, test y production:
El archivo de configuración de test es: config/environments/test.rb.
En el Gemfile, las gemas que estén en el grupo test solo están disponibles en ese ambiente.
En el archivo config/database.yml se encuentra la configuración de la base de datos de pruebas bajo la llave test.
Pruebas de modelos
Al crear un modelo con rails g model, se crean también:
Un archivo de prueba en la carpeta test/models (p.e. article_test.rb).
Un archivo para definir los datos iniciales en test/fixtures (p.e. articles.yml).
Lo principal que se debe probar en los modelos es:
Validaciones.
Scopes.
Métodos con lógica.
Veamos un ejemplo de pruebas de modelo:
1
require 'test_helper'
2
​
3
class ArticleTest < ActiveSupport::TestCase
4
  test "article is not created without a title" do
5
    article = Article.new
6
    assert_not article.save
7
  end
8
​
9
  test ".word_count returns the correct number of words" do
10
    article = Article.new(body: “Hola mundo. Esto es una prueba!”)
11
    assert_equal 6, article.word_count
12
  end
13
​
14
  test "published scope only returns published articles" do
15
    articles = Article.published
16
    assert_equal 1, articles.length
17
​
18
    assert_equal articles(:published).id, articles[0].id
19
  end
20
end
Copied!
Fixtures
Son archivos, escritos en formato YAML, que utiliza Rails para poblar la base de datos antes de ejecutar los tests. Existe un fixture por modelo.
Por ejemplo, si tenemos un modelo Author, debemos agregar los fixtures en test/fixtures/authors.yml:
1
pedro:
2
  email: [email protected]
3
  name: Pedro Perez
Copied!
En este ejemplo estamos definiendo un registro que llamamos pedro con valores para las columnas email y name.
Ahora, en las pruebas, nos podemos referir a ese registro como authors(:pedro). Por ejemplo:
1
test "pedro has the expected email" do
2
  assert_equal "[email protected]", authors(:pedro).email
3
end
Copied!
Puedes agregar varios registros en un mismo archivo. Por ejemplo, si tenemos un modelo Article podemos crear varios registros en test/fixtures/articles.yml:
1
published:
2
  title: Prueba 1
3
  body: Cuerpo 1
4
  published: true
5
​
6
unpublished:
7
  title: Prueba 2
8
  body: Cuerpo 2
9
  published: false
Copied!
En este caso nos podemos referir a cada registro de la siguiente forma:
1
articles(:published)
2
articles(:unpublished)
Copied!
Definiendo relaciones
En los fixtures puedes definir relaciones entre los modelos. Por ejemplo, si tenemos un modelo Article que pertenece a un Author, los podemos relacionar de la siguiente forma.
En el archivo authors.yml:
1
pedro:
2
  email: [email protected]
3
  name: Pedro Perez
Copied!
En el archivo articles.yml podemos relacionar el autor utilizando el nombre del registro:
1
published:
2
  author: pedro
3
  title: Prueba 1
4
  body: Cuerpo 1
5
  published: true
Copied!
Si la relación de Author y Article fuera una relación muchos a muchos se haría de la siguiente forma:
1
published:
2
  author: pedro, pablo, luis
3
  title: Prueba 1
4
  body: Cuerpo 1
5
  published: true
Copied!
La principal regla sobre los fixtures es nunca definir los ids directamente, Rails se encarga de eso automáticamente.
Pruebas de controlador
Las pruebas de controlador se encuentran en la carpeta test/controllers.
En este tipo de pruebas se simula una petición HTTP como si viniera del navegador.
Lo principal que se debe probar en los controladores es:
La seguridad. Que los usuarios sólo puedan ingresar a los recursos a los que tienen permisos.
Que cada acción del controlador retorne lo que esperamos.
Que las acciones de crear, editar y eliminar, creen editen y eliminen correctamente los registros.
Que las acciones de crear, editar y eliminar, no creen, editen o eliminen cuando la información que se les pasa no es valida.
Ejemplo que se encontraría en test/controllers/articles_controller_test.rb:
1
require 'test_helper'
2
​
3
class ArticlesControllerTest < ActionDispatch::IntegrationTest
4
  test "get index: is successful" do
5
    get articles_path
6
    assert_response :success
7
  end
8
​
9
  test "post create: creates an article"
10
    assert_difference 'Article.count', 1 do
11
      post articles_path, params: { article: { body: "El cuerpo", published: false, title: "El título" } }
12
    end
13
​
14
    assert_redirected_to article_url(Article.last)
15
  end
16
end
Copied!
Métodos disponibles
La clase ActionDispatch::IntegrationTest, de la cuál extienden las pruebas de controlador, exponen los métodos get, post, patch, put y delete para hacer las pruebas de controladores.
Ejemplos:
1
get "/articles"
2
get articles_path
3
get articles_path, params: { query: "batman" },
4
    headers: { "HTTP_AUTHORIZATION" => "..." }
Copied!
Igual para los demás métodos.
Assertions adicionales
Los siguientes son assertions adicionales que ofrece la clase ActionDispatch::IntegrationTest, de la cuál extienden las pruebas de controlador:
assert_difference: verifica que una expresión (p.e. Articles.count) haya cambiado por una diferencia definida. Por ejemplo:
1
  assert_difference 'Articles.count', 2 do
2
    Article.create(title: "Título 1", body: "Cuerpo", published: true)
3
    Article.create(title: "Título 2", body: "Cuerpo", published: false)
4
  end
Copied!
assert_response: verifica que la respuesta a una petición HTTP tenga el código de respuesta esperado. Puedes pasarle el código especifico (p.e. 200) o alguna de las siguientes símbolos:
:success - el código de respuesta está en el rango de 200 a 299 (exitoso).
:redirect - el código de respuesta está en el rango de 300 a 399 (redirección).
:missing - el código de respuesta fue 404.
:error - el código de respuesta está en el rango de 500 a 599 (error del servidor).
assert_redirected_to: verifica que la petición haya sido redireccionada a determinada ruta.
Assertions para las vistas
Existen dos formas que puedes utilizar para verificar que la vista contenga el contenido y los elementos que esperamos.
La primera forma es utilizar el método body que trae, como una cadena de texto (string), todo el resultado. Por ejemplo:
1
get articles_path
2
assert body.include?("Título 1")
Copied!
Una mejor forma es utilizar el método assert_select que recibe un selector y, opcionalmente, un texto:
1
get articles_path
2
assert_select "table.articles"
3
assert_select "h1", "Artículos"
Copied!
Integración con Devise
Para configurar Devise en Minitest agrega lo siguiente al final del archivo test/test_helper.rb:
1
class ActionDispatch::IntegrationTest
2
  include Devise::Test::IntegrationHelpers
3
end
Copied!
Ahora podemos utilizar el método sign_in en nuestras pruebas. Por ejemplo, en test/controllers/articles_controller_test.rb:
1
test "get index is successful if user is authenticated" do
2
  sign_in users(:pedro)
3
​
4
  get articles_path
5
  assert_response :success
6
end
Copied!
Envío de emails
El envío de emails se puede probar de forma aislada (pruebas unitaria) o dentro de nuestras otras pruebas (pruebas de integración).
El objetivo de las pruebas relacionadas con emails es asegurarse de que:
Los emails están son creados y enviados.
El contenido del email es el correcto (asunto, para, de, cuerpo, etc.).
Los emails correctos se están enviando en los momentos correctos.
Pruebas unitarias
Cuando creas un email utilizando el generador de Rails se crea un nuevo archivo en la carpeta test/mailers. Por ejemplo para una clase UserMailer vas a encontrar un archivo llamado user_mailer_test.rb.
Veamos un ejemplo de lo podríamos probar en ese archivo:
1
require 'test_helper'
2
​
3
class UserMailerTest < ActionMailer::TestCase
4
  test "invite" do
5
    # Guardamos el email para futuros assertions
6
    email = UserMailer.create_invite('[email protected]',
7
                                     '[email protected]', Time.now)
8
​
9
    # Enviar el email y verificar que fue encolado
10
    assert_emails 1 do
11
      email.deliver_now
12
    end
13
​
14
    # Verificar que el contenido es el esperado
15
    assert_equal ['[email protected]'], email.from
16
    assert_equal ['[email protected]'], email.to
17
    assert_equal 'You have been invited by [email protected]', email.subject
18
    assert_equal read_fixture('invite').join, email.body.to_s
19
  end
Copied!
Primero llamamos la clase UserMailer para enviar el email. Luego verificamos si el email es enviado utilizando el assertion assert_emails. Por último verificamos que el from, to, subject y el body sean los esperados.
Fíjate que la última línea de la prueba utiliza un método llamado read_fixture. Esto se utiliza para guardar la respuesta que esperamos dentro de un archivo, que en este caso debería llamarse invite y estar ubicado en la carpeta test/fixtures/user_mailer/:
1
Hola [email protected],
2
​
3
Has sido invitado.
4
​
5
Saludos!
Copied!
Pruebas de integración
Cuando algún controlador o modelo envía emails, queremos verificar que efectivamente sean enviados. Para eso utiliza el método ActionMailer::Base.deliveries, que retorna un arreglo de emails que se han enviado en la prueba:
1
require 'test_helper'
2
​
3
class UserControllerTest < ActionDispatch::IntegrationTest
4
  test "invite friend" do
5
    assert_difference 'ActionMailer::Base.deliveries.size', +1 do
6
      post invite_friend_url, params: { email: '[email protected]' }
7
    end
8
    invite_email = ActionMailer::Base.deliveries.last
9
​
10
    assert_equal "Has sido invitado por [email protected]", invite_email.subject
11
    assert_equal '[email protected]', invite_email.to[0]
12
    assert_match(/Hola [email protected]/, invite_email.body.to_s)
13
  end
14
end
Copied!
Pruebas de aceptación con Capybara
Las pruebas de aceptación son las más completas pero al mismo tiempo las más lentas.
Son lentas porque corren sobre un navegador. Por defecto se utiliza un emulador de un navegador, pero es posible ejecutarlas sobre Chrome o Firefox.
Las pruebas de aceptación se crean en la carpeta test/integration/.
Para crear pruebas de integración se utiliza una gema llamada Capybara que trae métodos para manipular el navegador como visit, click_link y fill_in. Por ejemplo:
1
test "user can register" do
2
  visit root_path
3
  click_link "Registrarse"
4
​
5
  fill_in "Email", with: "[email protected]"
6
  fill_in "Contraseña", with: "test1234"
7
  click_button "Registrarse"
8
​
9
  assert_equal articles_path, current_path
10
end
Copied!
La sugerencia es utilizar pruebas de aceptación para las funcionalidades críticas de la aplicación únicamente, y sólo el escenario normal en cada prueba.
Configuración
Para configurar Capybara debes incluir la gema en el grupo test de tu Gemfile. Por ejemplo:
1
group :test do
2
  gem 'capybara'
3
end
Copied!
En el archivo test/test_helper.rb debes agregar la siguiente línea después de los demás require:
1
require 'capybara/rails'
Copied!
También debes incluir la siguiente línea dentro de la clase ActionDispatch::IntegrationTest:
1
include Capybara::DSL
Copied!
Métodos útiles
Para navegar utiliza el método visit:
1
visit "/articles"
2
visit articles_path
Copied!
Para hacer click sobre links o botones:
1
click_link "Texto del Link"
2
click_link "id-del-link"
3
​
4
click_button "Texto del Botón"
5
click_button "id-del-botón"
6
​
7
click_on "Guardar" # puede ser link o botón
Copied!
Para interactuar con formularios:
1
fill_in 'First Name', with: 'John'
2
​
3
check 'A checkbox'
4
uncheck 'A checkbox'
5
​
6
choose 'A radio button'
7
​
8
select 'Option', from: 'Select box'
9
unselect 'Option', from: 'Select box'
10
​
11
attach_file 'Image', '/path/to/image.jpg'
Copied!
Para verificar si existe el contenido o algún elemento:
1
has_content?("Hola mundo")
2
has_no_content?("Hola mundo")
3
​
4
has_css?(".mi-selector")
5
has_no_css?(".mi-selector")
Copied!
Para buscar elementos:
1
find("#mi-selector").click
2
​
3
find_field("Nombre").value
4
find_field(id: "name").value
Copied!
Para limitar las acciones o las búsquedas:
1
within("#my-modal") do
2
  fill_in "Name", with: "Pedro"
3
end
Copied!