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!
Antes que nada felicitarte por el artículo ( y el blog en general, hay mucho conocimiento en él ). Creo que hacen falta mucho más en esta línea para acostumbrar a los front-end developers a trabajar de una forma «estandarizada».
Me parece que el testing y automatización de aplicaciones js es uno de los puntos más importantes antes de empezar un nuevo proyecto, ya que empezar un proyecto bien te puede hacer ganar mucho tiempo durante toda la vida del proyecto.
Ahora, me parece que más que realizar todas estas acciones ( generación de la estructura del proyecto, descargarte los fuentes, ejecutar los test incluso generar builds de tu proyecto ) manualmente, estaría bien echar mano de herramientas tipo karma o yeoman ( yo, grunt y bower ). Más info en http://yeoman.io/.
Si; estas herramientas son interesantes pero añaden una curva de aprendizaje que, por otro lado, asume que ya sabemos de qué estamos tratando. Grunt posiblemente lo usemos en los últimos pasos del «curso» para automatizar las pruebas. La idea es que, después de tener una noción sólida de qué es el testing y cómo se estructura una App de forma «profesional», comencemos a ver las ventajas que pueden ofrecer las soluciones «todo en uno» como Yeoman.
Gracias por el comentario;
Saludos!
De nada, será interesante seguro!
Yo hace poco que lo he empezado a usar en las «single web page applications» que desarrollo, y una vez que le pillas el tranquillo es todo un gustazo.