¿Como realizar pruebas con Rspec?

Como realizar pruebas en Rspec

En este post, más allá de como utilizar la herramienta para poder realizar pruebas a un proyecto Rails, tiene la intención de facilitar el proceso mental de definir una prueba para asegurar que definida característica cumple su objetivo, tomando ventaja de las herramientas que ofrece Rspec*.

También quisiera acotar algo que es un mito dentro del concepto de TDD, el tener que realizar la prueba anterior a el desarrollo del feature, esto no es enteramente cierto, normalmente el proceso es una iteración continua entre el desarrollo y la prueba, esto debido a que cuando desarrollamos solemos darnos cuenta de casos borde que tenemos que cubrir.

Partamos entonces conociendo 3 palabras clave que nos provee Rspec, que son: describe, context e it. Estas palabras hacen que sea super descriptiva la manera de definir comportamiento, casi como lenguaje natural. Este es un ejemplo de una prueba con las 3 palabras mencionadas:

Rspec.describe YourNameClass do
    describe "feature/method" do
        context "when the user is not the owner of the resource" do
            it "should behave in some way" do
            end
        end

        context "when the user is the owner of the resource" do
            it "should behave in other way" do
            end
        end

        context "when the resource has no owner" do
            it "should throw an error message" do
            end
        end
    end
end

En el ejemplo mostrado vemos un patrón: - describe como su traducción lo indica esta para ofrecer detalles de que funcionalidad se esta probando - context en general viene acompañado con un "when", para especificar como se comporta dicha funcionalidad descrita cuando un escenario se presenta, para una funcionalidad pueden haber tanto escenario como casos borde logres identificar - it esta es la prueba como tal, normalmente acompañada por un "should" y define como debe comportarse la funcionalidad dentro del contexto/escenario señalado.

Esta estructura puede ser intercambiable, fácilmente dentro de un context podemos tener definido un describe para especificar una subfuncionalidad de una funcionalidad mayor.

Gracias a estas palabras claves, al ejecutar las pruebas con formato documentado, si alguna llega a fallar no solo te mostraria "....F.." como esta por defecto, de lo contrario te mostraría algo muy similar a

describe feature when the user is not the owner of the resource it should behave in some way

Esto hace que sea más sencillo identificar que es lo que falla dentro de nuestro aplicativo.

De manera personal, si una funcionalidad se torna extensa de probar o es complejo implementar la prueba, suelo definir el happy path y los casos borde que identifique sin realizar la implementación de ninguna, y le hago skip con la palabra clave xit, de esta manera Rspec es consciente que existe la prueba sin embargo no se ejecuta y te manda una alerta de que tienes que implementarla. Y si a medida que desarrollo la funcionalidad, logro identificar otro caso borde simplemente agrego la definición, la practica es la que va a determinar con que velocidad implementas la prueba, por eso no te preocupes si eres lento para esto, es de las cosas que solo con mucha practica se mejora.

describe "#method" do
    context "when something happen" do
        xit "should behave in some manner" do
        end
    end
end

Este es el primer post de un conjunto, estare especificando como hacer pruebas modelos, controladores, helpers, POROs, etc.