Define cada uno de los términos #107

Además, hace una serie de aclaraciones sobre el desarrollo del proyecto

documentos/proyecto/2.Tests.md

@@ -12,7 +12,8 @@ relación estrecha con las HUs.
 
 ## Prerrequisitos
 
-Haber superado [el hito anterior](1.Infraestructura.md).
+Haber superado [el hito anterior](1.Infraestructura.md), es decir, pasar los
+tests de ese hito.
 
 ## Explicación
 
@@ -36,7 +37,11 @@ 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.
+> 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
@@ -51,9 +56,16 @@ el [hito anterior](1.Infraestructura.md).
   generalmente se confronta TDD frente
   a [BDD](https://en.wikipedia.org/wiki/Behavior-driven_development),
   pero por eso precisamente tienes que justificar el estilo elegido.
-- Buscar un sistema de prueba del código, una librería o marco, que
-  sea estándar y flexible; como en el caso anterior, también se tiene
-  que justificar esa elección.
+- 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.
@@ -62,7 +74,8 @@ el [hito anterior](1.Infraestructura.md).
   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`. El
+  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.