La infraestructura virtual tiene que ser testeada, porque código que no está probado, está roto. El crear los tests y una forma automática de ejecutarlos es un paso previo a llevar a cabo tareas de integración y despliegue continuo (que se verán a continuación).
Haber alcanzado el 60% de los objetivos del tema introductorio tras haber realizado los ejercicios propuestos.
En sistemas de desarrollo ágil quien desarrolle tiene que asegurar que
el código pasa todos los tests antes de ser desplegado o simplemente
incorporado a la rama master, porque los tests son la especificación
de los requisitos. Para ello se escriben
una serie de tests que se ejecutan automáticamente al añadir o
modificar código o cuando se solicite un pull request. Estos
tests tienen el fin obvio de asegurar la calidad del mismo, pero
también en un entorno de desarrollo colaborativo permiten integrar
código fácilmente asegurándose de que no se rompa nada. Si no está
testeado, está roto, es el lema del desarrollador. Al ser la
plasmación de las especificaciones, en cada incorporación de código la
ejecución automática de los tests asegura que el código sigue
cumpliendo las especificaciones.
Aunque más adelante habrá que hacer tests de todo el código que se vaya a desplegar, en este hito es suficiente con que se cree una biblioteca o clase, que será la base del servicio que se vaya a escribir, y que se hagan pasar los tests para la misma, sin necesidad de escribir un programa principal o servicio que los use (lo que habrá que hacer en hitos posteriores). Los tests son de funciones (o métodos) y unitarios, y como tales lo pasan las funciones. De hecho, en TDD (desarrollo basado en test) se escriben los tests antes que las funciones; continuando con la gestión del proyecto iniciada en el hito anterior, las especificaciones y las funcionalidades tendrán que estar en un issue y este en un hito. No se cerrará ningún issue y ninguna historia de usuario sin hacer el test correspondiente que se asegure que funciona.
Hacer los tests no es suficiente. Hay que automatizar la ejecución de
los tests usando las herramientas de construcción o de gestión de
tareas del lenguaje que se esté usando; por ejemplo, incluir un
objetivo make test dentro de un Makefile. Normalmente, estas
tareas u órdenes son estándar para cada lenguaje y generalmente
también Travis (o el sistema que elijáis) las ejecutará
automáticamente salvo que le digas lo contrario. En algunos casos,
como Python, las herramientas de construcción como pip solo
necesitarán un fichero requirements.txt que instale las
dependencias, si las hubiera; sin embargo, en otros lenguajes el
fichero de tareas correspondiente permitirá especificar
dependencias, versión del lenguaje, instrucción específica que se va
a usar para hacer test y también metadatos adicionales como licencia
o autor.
El material del curso cero incluye varios temas relacionados con el desarrollo basado en test. Se recomienda encarecidamente que se entiendan los conceptos.
Sobre los task runners o gestores de tareas.
Como crear objetos de test.
Como ejecutar los tests.
Se tendrá que haber actualizado el repositorio que se usara en los hitos anteriores y añadir al fichero de este hito el nombre del proyecto, el autor y un enlace al mismo y hacer un pull request.
La descripción del proyecto tiene que seguir progresando, así que el
README.md tiene que incluir una descripción real de la clase que se vaya a
testear, como instalarla y testearla y qué uso va a tener dentro del servicio
(o servicios) web que se van a desplegar más adelante. En un proyecto el
README.md debe estar escrito para la persona que llegue, y no para que se
corrija. Si hay documentación adicional, tendrá que enlazarse desde este
README.md.
Habrá que añadir al fichero iv.yaml las siguientes claves:
lenguaje tendrá el lenguaje de programación usado.test apuntará a uno de los ficheros, o el fichero, que se use para
testear.taskfile apuntará al fichero que se va a usar, a partir de ahora,
para ejecutar diferentes tareas. En ese fichero, que será específico
del lenguaje en algunos casos (en otros será genérico, como un
Makefile), se tendrán que ir poniendo todas las tareas que se hagan
en el proyecto, empezando por make install o make installdeps y
continuando, en este mismo, con make test.Se recuerda que es prerrequisito haber llevado a cabo el 60% de los objetivos del tema correspondiente de la asignatura y del resto de las sesiones hasta el momento de la entrega. En caso contrario no se evaluará este hito del proyecto. Como es habitual, se recuerda al alumno que no se trata simplemente de marcar las cosas que se tienen que hacer para este hito, sino que al proyecto en esta etapa refleje que se ha entendido correctamente el concepto de un proyecto integrado de forma continua.
Si se cumplen los requisitos, la puntuación se distribuirá en las siguientes rúbricas:
Se podrá bajar la calificación si
Se recuerda también que este es un hito de un proyecto, y como tal los tests para este hito incluyen los de todos los anteriores; el proyecto tendrá que seguir desarrollándose de acuerdo a lo indicado en el hito anterior y tener como mínimo la estructura que se creó en el hito 0.