General

Ya hemos visto en la entrega anterior las herramientas que vamos a utilizar pero, igual de importantes que éstas, es la distribución de ficheros que deberíamos emplear en un proyecto al que queremos aplicar tests de la forma más correcta o estándar posible.

Por lo general, los tests se recogen en ficheros independientes asociados a la vista, modelo, controlador o biblioteca sobre la que están actuando; en otras palabras, lo habitual es crear un fichero de tests por cada fichero que queremos testear.

La nomenclatura clásica establece una estructura donde todos estos ficheros quedan recogidos en un único directorio base denominado ‘test’. En su interior, podemos encontrar a su vez otras subcarpetas para clasificar las ‘suites’ según actúen sobre una u otra categoría y que suelen reflejar de forma fidedigna la estructura original del proyecto. Dicho de otro modo, en el interior de la carpeta ‘test’ tendríamos que encontrar una copia idéntica del árbol de ficheros de nuestra aplicación como si de un espejo se tratase:

 
        - js
	-- libs
	-- models
	-- routers
	-- views
	-- app.js
	- test
	-- libs
	-- models
	-- routers
	-- views
	-- app-test.js

Mientras que el nombre de las carpetas se corresponde con el original, a los ficheros se les añade el sufijo ‘-test’ para diferenciarlos. De este modo, tendríamos por ejemplo el siguiente árbol:

 
	- js
	-- views
	---- components
	------ enjoy-component-header.js
	------ enjoy-component-login.js
	------ enjoy-component-play.js
 
	- test
	-- views
	---- components
	------ enjoy-component-header-test.js
	------ enjoy-component-login-test.js
	------ enjoy-component-play-test.js

Dependencias

Cuando hablamos de dependencias, es habitual almacenarlas ‘fuera’ de los directorios reservados para el código fuente del proyecto. Para ello, los diferentes ficheros que proporcionan tanto el entorno de tests como sus diversas funcionalidades, suelen guardarse dentro de la propia carpeta ‘test’ en un subdirectorio denominado ‘vendor’.

La práctica anterior daría como resultado una estructura similar a la siguiente:

 
	- test
	-- vendor
	---- chai.js
	---- jquery.js
	---- mocha.js
	---- sinon.js
	---- sinon-chai.js

En este ejemplo se ha optado por incluir incluso una copia nueva de jQuery, una biblioteca que participa tanto de la aplicación como de los tests. Esto es para preservar la retrocompatibilidad con la infraestructura de tests en caso de que se actualice en la aplicación a una versión no compatible con alguna de sus dependencias en esta capa. Por lo tanto, es interesante contar con copias de las principales bibliotecas que estemos utilizando en nuestro proyecto en lugar de vincular directamente las originales. Esto, además, permite cierta independencia de los tests con respectos al resto del código.

Consistencia con los nombres

Además de la estructura, es importante ser consistente a la hora de nombrar los ficheros. Las buenas prácticas (y las que con más frecuencia encontraremos en códigos de terceros) aconsejan seguir las convenciones. Para ver algunas de estas recomendaciones, podemos ojear el artículo «Guía de estilo. Nomenclatura en archivos Javascript» que escribí en este mismo blog hace algún tiempo.

NOTA: El citado artículo contenía las prácticas más habituales que podíamos encontrar en 2012; desde entonces, si revisamos los proyectos punteros en servicios como GitHub, poco ha cambiado el paronama a excepción quizá de los nombres compuestos: las tendencias actuales parecen preferir el guión medio al bajo a la hora de separar nombres compuestos. Nosotros, para esta serie, utilizaremos también en los ejemplos el guión medio.

Conclusión

Llegados a este punto, tenemos por un lado identificadas tanto las herramientas a utilizar como dónde ubicarlas. En la siguiente entrega, veremos cómo configurar el entorno de pruebas para que actúe de forma desantendida y presentaremos la estructura básica de una suite de tests.

Como siempre, cualquier comentario con lo visto hasta ahora es bienvenido!