Introducción

Continuamos con nuestra serie de tutoriales sobre testing moderno para, en esta ocasión, echarle un vistazo a cómo es un bloque de test (también llamado suite) tal y como lo usaremos más adelante. Recordemos que, aunque hemos escogido MOCHA como framework para estas pruebas, la idea es similar para cualquier otro. Del mismo modo, incluso las sintaxis entre bibliotecas no cambia demasiado por lo que, si escogemos otro paquete, únicamente deberíamos revisar su documentación y traducir los siguientes ejemplos.

Metámosnos en materia…

Estructura básica de un bloque de tests

Testear aplicaciones en Backbone es similar a testear cualquier otro tipo de software. Sin embargo, dado que estamos ante una estructura de tipo MVVM (evolución del clásico patrón MVC), es interesante centrarse precisamente en el análisis de los modelos y las vistas.

Al ser estas estructuras partes de un todo, es importante que al arrancar nuestros tests podamos iniciar o acceder a determinados métodos y propiepades ‘compartidas’ que se utilizan durante las pruebas. Estaríamos hablando aquí de por ejemplo instanciar objetos, crear mocks, establecer espías, iniciar alguna variable con un valor que requerimos durante las pruebas, etc…

Para ello, MOCHA, al igual que cualquier otro framework de tests, ofrece dos métodos o funciones dentro de cada bloque (recuérdese que un bloque de tests es aquel que hemos definido mediante el comando ‘describe‘) que se ejecutan antes y después de correr todos los tests unitarios (que definimos anteriormente como funciones ‘it’). Estos métodos son beforeEach() y afterEach(). Veamos un caso de uso típico para pintar después el escenario al que se corresponde:

describe( "Persistence", function () {
 
  beforeEach( function() {
    this.todo = new todoApp.Todo();
    this.save_stub = sinon.stub( this.todo, "save" );
  } );
 
  afterEach( function () {
    this.save_stub.restore();
  } );
 
  it( "should update server when title is changed", function () {
    /* ... */
  } );
 
  it( "should update server when status is changed", function () {
    /* ... */
  } );
 
} );

El ejemplo anterior es prácticamente un clásico entre los programas de iniciación a los tests. En él, podemos ver un bloque o ‘describe‘ que enmarca a dos tests unitarios o ‘it’s. Además de esto, como se presupone que estos dos últimos actúan sobre un objeto (‘todo‘ en este caso), necesitamos que el mismo esté ‘disponible’ una vez empecemos las comprobaciones. Del mismo modo, y si observamos el título del bloque (‘Persistence‘), podemos intuir que queremos comprobar precisamente la persistencia de ese objeto.

Con estos datos en la mano, queda claro que estamos actuando sobre un modelo de Backbone, o su equivalente en cualquier otro framework.

NOTA: Recordamos llegados a este punto que en cualquier arquitectura de tipo MVC o derivada, un modelo es la capa que se encarga de alterar el estado de un objeto mediante el registro de sus estados. Este comportamiento suele corresponderse con la escritura, lectura o actualización de un dato en una BD u otro sistema de almacenamiento ya sea de forma temporal o, como se especifica en este ejemplo, persistente.

Pensemos por ejemplo que esta persistencia que queremos comprobar exige de una base de datos que guarda el estado de nuestro objeto ‘todo’. Dicha base de datos bien puede no existir aún (dado que en la metodología TDD estamos escribiendo el test antes de implementar nada) o que, pese a que exista, no hay aún una lógica que permita conectarnos a ella para interactuar (una API). Esto que en principio podría parecer prioritario, no lo es bajo un paradigma de tests: podemos aislar cada componente o pieza funcional de modo que podamos avanzar en su desarrollo con independencia del resto. En este caso, recurrimos a lo que anteriormente definimos como un ‘stub‘: nuestra herramienta (Sinon) escuchará las posibles llamadas que realicemos a la API (aún ficticia) de nuestra base de datos para interceptarlas y simular con ello que efectivamente está tanto disponible como en funcionamiento.

Resumiendo los últimos párrafos, nuestros bloque de test requiere de dos condiciones previas para ejecutar sus pruebas unitarias:

• Que exista una instancia del objeto a comprobar (llamado en la terminología de testing ‘SUT‘).
• Que esté disponible (o emulada) una API a través de la cual se desarrolle la lógica de persistencia.

Para cubrir ambos aspectos en el ejemplo anterior se ha añadido el método beforeEach:

beforeEach( function() {
    this.todo = new todoApp.Todo();
    this.save_stub = sinon.stub( this.todo, "save" );
} );

NOTA: Dentro de cada bloque, el framework maneja el valor ‘this‘ de forma inteligente de modo que siempre hace referencia al contexto del test independientemente desde donde lo invoquemos.

La primera sentencia crea una instancia del objeto ‘todo‘ a través del constructor que tendremos que definir más adelante; la segunda crea un ‘stub‘ que interceptará cualquier llamada al método ‘save‘ (segundo parámetro de la función) anulándola. Es decir, cuando se trate de ejecutar ‘todo.save()‘, Sinon capturará la llamada no permitiendo que ésta se efectúe y lance un error al no estar disponible. Estamos así ‘controlando’ o ‘redirigiendo’ el flujo real de nuestra aplicación según nos interesa.

Al finalizar los tests unitarios pertinentes, eliminamos nuestro ‘stub‘ anterior devolviendo el control del flujo al programa mediante la función afterEach(). Gracias a esto, cualquier llamada posterior a ese método todo.save() si que lanzaría el correspondiente error de tipo ‘todo.save is not a function‘.

Básicamente este es el esquema o patrón para realizar los tests:

• Se ‘describe’ un bloque que agrupa varios tests unitarios relacionados de alguna forma ‘lógica’.
• Se inician/intancian todas las variables u objetos que podemos precisar durante los tests y que estarán accesibles a todos de forma global.
• Se emulan/interceptan/escuchan todas aquellas funcionalidades que nos interesen durante el transcurso de los tests.
• Escribimos los tests unitarios necesarios.
• Se dejan de emular/interceptar/escuchar todas las funcionalidades marcadas anteriormente para devolver el control normal a la aplicación.

Conclusion

En este breve capítulo, hemos visto la forma de estructurar una cadena de tests utilizando la nomenclatura habitual de este paradigma: suite, describe, before, after, it… Dado que es algo que hay que asumir e interiorizar, no extiendo más la explicación y dejo así tiempo para la reflexión 😀

Como comentamos en la introducción, estos nombre suelen ser comunes a los marcos de tests más habituales por lo que, aunque se está tratando de forma concreta a MOCHA, pueden resultar igual de válidos para otras soluciones similares.

Nos vemos en la siguiente!