Escribir pruebas automatizadas es bueno para el software que creamos. Es una forma de dar garantía de que lo que hacemos funciona cómo debería en la mayoría de escenarios normales.
De todos modos, no es fácil acostumbrarse a testear cuando no se enseña desde que se aprende a programar.
Una de las cosas buenas de Ruby on Rails es que la ponen fácil para uno meterse al mundo del testing. Tiene su propio framework de pruebas llamado Minitest y permite integrar con pocos pasos otra librería llamada RSpec.
Cuando uno empieza a escribir pruebas aprende un montón de cosas y terminología y es ahí donde uno puede encontrar una confusión con respecto a los términos Mock y Stub.
¿Para qué «mockear» o «stubear»?
Primero que nada, uno solo debería recurrir a mocks cuando se trate de pruebas que tengan que interactuar con servicios de terceros (APIs externas). Ejemplo, al momento de escribir pruebas para una integración con Mailchimp no vamos a permitir que los tests hagan peticiones directamente. Sería muy lento y hasta riesgoso.
Lo que se hace en esos casos es poner objetos falsos que actúen como dicho servicio externo. Aquí es donde entran los mocks o stubs.
Ejemplo de eso es esta porción de código donde escribo una prueba de una clase que interactúa con AWS Athena:
let(:age_distribution_service) { instance_double(AgeDistributionChartService) }
let(:valid_access_token) { JsonWebToken.access_token }
let(:athena_client) { instance_double(Aws::Athena::Client) }
before do
allow(Aws::Athena::Client).to receive(:new).and_return(:athena_client)
allow(athena_client).to receive(:get_query_results)
Al usar la función instance_double estoy generando un objeto falso que se interpone entre el servicio y las pruebas y de igual forma hacer que estas sean exitosas.
Todo muy lindo pero entender eso me llevó tiempo de uso a ciegas y también tratando de entender qué pasa ahí o por qué tuve que usar las funciones:
allow(object).to receive(:method).and_return(result)
Y fue cuando leyendo la documentación de la gema rspec-mocks encontré muchos términos confusos y no entendía nada. Así que en definitiva, ¿cuál es la diferencia entre un mock y un stub? ¿No bastaba con lo que ya hacía?
La diferencia es sutil y la descubrí luego de leer un artículo al respecto en el blog de Jason Swett. Al final también descubrí que como uso RSpec da lo mismo ya que este framework de pruebas no hace distinción.
Un mock es un objeto falso que se usa en lugar de uno real con el propósito de escuchar a los llamados a sus métodos.
Un stub es un objeto falso que se usa en lugar de uno real con el propósito de hacer que el programa se comporte de forma necesaria para poder testearlo.
Jason dice que:
Stubs ayudan con entradas (inputs) y mocks con ayudan con las salidas (outputs)
Jason Sweet
Así que eso es todo el asunto. Son objetos falsos para ayudarnos en las pruebas sea para comportamiento o para asegurar que las salidas sean las adecuadas y permitir que el testeo sea exitoso.
En el ejemplo de arriba, esto es stub:
let(:athena_client) { instance_double(Aws::Athena::Client) }
Y esto es mock:
allow(Aws::Athena::Client).to receive(:new).and_return(:athena_client)
Al usar RSpec esa terminología se hace un poco innecesaria de saber de manera teórica o filosófica pero por si las dudas aquí queda explicado.
Lo importante es que hay que escribir pruebas y cuando sean para probar interacciones con servicios de terceros hay que «mockera».
Otro Espacio Blog 