Segundo Hito: Tests

Objetivo

El principal objetivo de este hito es añadir tests y una descripción inicial de la infraestructura virtual a la aplicación a los gestores de dependencias y/o tareas, la necesaria para que se ejecuten los tests.

Los subobjetivos son entender los conceptos de tests funcionales/unitarios y su relación estrecha con las HUs.

Prerrequisitos

Haber superado el hito anterior, es decir, pasar los tests de ese hito.

Explicación

En sistemas de desarrollo ágil cada entidad tiene que asegurar que pasa todos los tests antes de ser desplegada. Para ello se escriben una serie de pruebas, (generalmente) fuera del código en sí de la aplicación, como scripts independientes, que se deben siempre pasar al añadir, solicitar cambios (mediante PR) o modificar código.

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; por otro lado, permiten también la creación de un entorno en el que se defina de forma precisa la infraestructura necesaria para crear el proyecto. Un sistema de integración continua usará todo tipo de tests, pero en este hito nos vamos a centrar en los tests unitarios. Precisamente por el hecho de que se trata de asegurar la calidad del código, esta no se puede asegurar si no están hechos de acuerdo con las HU creadas en el proyecto. Los tests se aseguran de que añadidos posteriores no rompan el código, pero primero y principalmente que el código se comporta como las HUs (e issues que se deduzcan de ellas) dice que debe de comportarse.

Lo importante es que los tests están siempre ligados a la lógica de negocio a través de las historias de usuario y de los issues donde se planteen los problemas de implementación. Adicionalmente, el estado en el que esté el proyecto una vez que haya alguna parte de la lógica de negocio funcionando posiblemente necesite un hito del proyecto para describirlo y enmarcar todos los issues, tanto de desarrollo de las HUs como de infraestructura, necesarios para a cabo.

Preparar un proyecto para integración continua implica varios pasos. El primero, elección del gestor de tareas (desde donde se deberá ejecutar) ya se ha hecho en el hito anterior.

Elegir una biblioteca de aserciones que permita llevar a cabo, fácilmente, la comparación entre resultado esperado y obtenido. Esta elección se tiene que llevar a cabo incluso cuando el lenguaje incluya una biblioteca de aserciones estándar. Puede haber bibliotecas más potentes, o simplemente usar otro estilo: generalmente se confronta TDD frente a BDD, pero por eso precisamente tienes que justificar el estilo elegido.
Buscar un sistema de prueba del código, es decir, un test runner que encuentre, ejecute y escriba informes sobre los tests siguiendo las buenas prácticas en el lenguaje correspondiente. Se tratará, en general, de una librería o marco, casi siempre acompañada de una herramienta de línea de órdenes, que siga los estándares y sea flexible; como en el caso anterior, también se tiene que justificar esa elección, porque en la mayoría de los lenguajes habrá varias opciones donde elegir. En algunos casos los test runners son parte de un testing framework que incluye también bibliotecas de aserciones, pero se tendrá que justificar la elección de cada uno de ellos de forma independiente”.
Si no se ha hecho, describir en un fichero de tareas usando la herramienta de tareas elegida las tareas más comunes del proyecto: compilación o comprobación de sintaxis de programas, por ejemplo.
Si no se ha hecho, escribir una serie de tests unitarios que cubran una parte, si es posible considerable, de la funcionalidad del proyecto.
Integrar las pruebas dentro de las herramientas de construcción del proyecto usando las convenciones estándar de la herramienta y el lenguaje; por ejemplo, incluir un objetivo make test dentro de un Makefile (si ese es el gestor de tareas que se ha elegido). El uso de estas herramientas de construcción permite que tanto en local como en remoto, se lancen los tests exactamente de la misma forma.

Una vez comprendido el flujo de trabajo que lleva a los tests, podremos pasar a las fases siguientes.

Recursos adicionales

Material correspondiente de la asignatura: Desarrollo basado en pruebas.

Adicionalmente, 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.

Entrega de la práctica

De la forma habitual, editando el fichero con un enlace al repo y un número de versión que se incrementará con cada hito y también con cada envío adicional (en este caso la versión menor).

Habrá que añadir al fichero cc.yaml las siguientes claves:

lenguaje tendrá el lenguaje de programación usado.
test apuntará a uno de los ficheros, o el fichero, o los ficheros, que se usen para testear.
fichero_tareas 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, en general, el README.md se usa solamente para una explicación general del proyecto, inclusive instrucciones para su construcción y testeo. Para explicar diferentes decisiones relativas al mismo quizás sea conveniente o crear una rama gh-pages (que se publica automáticamente en GitHub), un subdirectorio a partir del cual se genere esa rama, o simplemente un subdirectorio para la documentación que se irá enlazando desde el README en todo lo necesario para corregir el hito.

Valoración

Esta es la puntuación de las diferentes rúbricas. En tocas ellas se tendrá que tener en cuenta que lo importante no es la “elección correcta”, sino mostrar que el estudiante tiene madurez para tomar una decisión técnica que afectará al resto del proyecto.

2 puntos: Elección y configuración del gestor de tareas.
2 puntos: Elección y uso de la biblioteca de aserciones.
2 puntos: Elección y uso del marco de pruebas.
4 puntos: Correcta relación entre avance de código (incluyendo los tests) e HUs, incluyendo testeo de algunos aspectos de la lógica de negocio. Uso correcto de milestones para esto.

Este hito contribuirá 0.75 puntos a la nota final