📝 ♻️

Author: JJ

documentos/proyecto/4.Tests.md

@@ -2,23 +2,24 @@
 
 ## 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 unitarios 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).
+Eventualmente, hay que tratar de resolver los problemas del cliente
+implementando la lógica de negocio. Y este código tiene que ser testeado, porque
+código que no está probado, está roto. El crear los tests unitarios 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 pasado los tests del [objetivo
-anterior](http://jj.github.io/IV/documentos/proyecto/3.Automatizar).
+Haber entregado correctamente el [objetivo
+anterior](http://jj.github.io/IV/documentos/proyecto/3.Automatizar), así como
+todos los anteriores.
 
 ## TL;DR
 
 En este objetivo se trata de entender bien el problema del usuario y dividirlo
 en una serie de problemas más simples (*issues*) cuya solución pueda ser
-fácilmente testeable y que conduzcan a la solución del problema más complejo que
-aporta valor al cliente.
+fácilmente testeable. La solución de estos issues llevará a la solución del
+problema más complejo que aporta valor al cliente.
 
 Lo que se busca no es que se escriban tests, ni siquiera que se escriba
 código. La ingeniería implícita en este objetivo es la capacidad de plantear
@@ -39,16 +40,14 @@ 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.
+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.