4.Tests.md

Objetivo 4: Tests

Descripción

Antes de desplegar a la infraestructura virtual, el código tiene que ser testeado, porque código que no está probado, está roto. El crear los tests y, eventualmente, 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).

Prerrequisitos

Haber realizado el objetivo anterior.

Explicación

En sistemas de desarrollo ágil quien desarrolle tiene que asegurar que el código cumple todos los requisitos antes de ser desplegado o simplemente incorporado a la rama principal; los tests son la implementación de esos requisitos.

Y los requisitos salen del problema original, pasando por las historias de usuario y los issues correspondientes.

Para ello se escriben una serie de tests que (eventualmente) se ejecutarán automáticamente al añadir o modificar código o cuando se solicite un pull request. Estos tests sobre el código 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.

Pero nosotros ejecutaremos los tests automáticamente sólo a partir de los siguientes objetivos.

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 trabaje sobre la biblioteca o clase que se ha hecho en el objetivo anterior, 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, y lo hacen de forma independiente. De hecho, en TDD (desarrollo basado en test, Test Driven Development) 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.

Evidentemente, en este objetivo es cuando hay que introducir la lógica de negocio, porque lo principal que se va a testear es esa lógica que añade valor al producto. No hace falta que se introduzca toda la funcionalidad de la misma, pero antes de hacer cualquier despliegue hay que hacerlo, así que es mejor empezar ya; por ejemplo se puede introducir alguna lógica de validación, que va a ser previa a la lógica de negocio (e imprescindible si se usan lenguajes que no tengan un sistema de tipos adecuado). Si en el hito anterior sólo se han declarado objetos valor, en este tendrá que haber entidades, que son los módulos que contienen la lógica de negocio.

Recursos adicionales

El material del curso cero incluye varios temas relacionados con el desarrollo basado en test. Se recomienda encarecidamente que se entiendan los conceptos.

• Como crear objetos de test.

• Como ejecutar los tests.

Lista de comprobación

En este objetivo se sigue la metodología de desarrollo de todos los objetivos, como es natural. Especialmente, hay que seguir usando issues para avanzar en el código. Por eso conviene repasar la lista de comprobación de los mismos, incluida en otro objetivo.

Copia y pega en tu PR, lleva a cabo esta lista de comprobación sobre tu código, y marca todo lo que hayas hecho.

* [ ]  ¿Hay un camino claro que permita ir desde el código hasta la historia de
   usuario que desarrolla, pasando por el mensaje de commit y el issue
   correspondiente?
* [ ]  ¿Se ha intentado cubrir una parte de la lógica de negocio que se
   esté desarrollando?
* [ ]  ¿Hay un producto mínimamente viable que describa lo que se va a entregar en
   este objetivo?
* [ ]  ¿En este producto mínimamente viable se han priorizado unas clases,
   módulos o paquetes más fundamentales frente a otros, movidos a otro
   PMV/Hito?
* [ ]  ¿Se han documentado las elecciones de biblioteca de aserciones y de
   *framework* de test?
* [ ] ¿Esa documentación incluye criterios de aceptación y también criterios de
búsqueda para las diferentes opciones?
* [ ]  ¿Se han seguido los principios F.I.R.S.T. en la creación del test y
   se ha documentado cómo se ha hecho?
* [ ]  ¿Se describe claramente en el PMV los tests que hay que pasar para que se
   considere viable?

Entrega de la práctica

Se tendrá que haber actualizado el repositorio que se usara en los hitos anteriores y añadir al fichero de este hito la URL del PR en el repositorio que haya correspondido, y la versión.

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:

• test apuntará a uno de los ficheros, o el fichero, que se use para testear.

Objetivos a alcanzar

1. Aprender a elegir herramientas para llevar a cabo tests.
2. Aprender a plasmar la lógica de negocio en código, y a testear su correcto funcionamiento mediante los tests. Este es evidentemente el subobjetivo más importante de este objetivo.
3. Aprender a integrar las tareas como esta en la herramienta que haya de gestión de tareas.

Valoración

El alcanzar este objetivo avanzará, en principio, 15% de la puntuación de este apartado de la asignatura.