Los test unitarios deben ser en ejecución.

Los test unitarios, por deficion, son trozos de codigo que se ejecutan para probar otras partes de codigo. Estas partes se prueban de forma aislada, sin tener en cuenta la integracion con otras partes del sistema.

Este planteamiento es correcto pero tal y como estan pensados los frameworks de hoy en dia (Junit, testGN, etc..) los trozos de codigo deben de ser demasiado simples. Siempre que ves un ejemplo tienes algo como esto:

Probar la funciona

int suma (int a, int b){
             return a +b;
}

Y ejemplo te indica con todo lujo de detalles como probar esta funcion pero que pasa si:

• La funcion depende de base de datos.
• La funcion depende de un web services al que se conecta.
• La funcion depende de una cache de datos que solo se inicializa en casos muy concretos.
• Etc (y este etc es muy largo)

Cualquier programador que haya participado en el desarrollo de una aplicación medio compleja sabe que la unica manera fiable de probar un procedimiento es en ejecucion. Por lo que LOS TEST UNITARIOS SE DEBERIAN LANZAR EN EJECUCIÓN.

Hay framewoks como MOQ que se hacercan a esta visión de las pruebas unitarias. La idea es buena pero simular algo no es lo mismo que verlo funcionar. Ademas, los test suelen ser costosos de programar y la mayoria de tiempo de desarrollo se gasta en preparar el MOQ y lo que deberia llevarse mas tiempo de desarrollo es probar la propia logica del metodo que quieres probar.

Lo que se debe hacer para lanzar test unitarios es ejecutar la aplicación tal cual. Y una vez que este arrancada que una parte se ejecute en ultimo lugar y lance las pruebas de los metodos. De metodos de verdad, es decir no es lo mismo hacer la prueba de metodo "suma(int a, int b)" que el metodo "altaAlumno (Alumno alumno, Clase clase, Centro centro)" <-- Creo que se deduce facil la diferencia en la complejidad.

Plantear el desarrollo de una tarea

En el dia a dia de un proyecto (de desarrollo de una aplicación informática) lo mas común es afrontar la implementación de una tarea.

       ej) Se esta implementando el proyecto "Portal de gestión de alumnos" y se quiere empezar con la tarea "Pagina de alta de alumnos". Una vez recogidos los requerimientos, hecha la planificación. se ha hecho el diseño, etc... (ya se tienen todos los pasos previos al desarrollo) ya podemos empezar con el desarrollo. No mas normal es tener una planificación como la siguiente:

Una tarea se divide en subtareas que se pueden o no solapar entre si. En las solapadas podemos poner a varios programadores (uno con cada tarea ques pueda solapar) y asi optimizar el tiempo de desarrollo de la tarea total.

El planificador de la tarea es el que ha decidido que la subtarea 1 y la 2 no se pueden solapar. Esta decision hay que respetarla. Pero se puede paralelizar. La respuesta es si.

Normalemente esta subtarea se asigna a un solo programdor (el principal motivo de asignar a un solo programador es que el tiempo de coordinacion y comunicacion entre programadores perjudicaria demasiado al desarrollo) pero una subtarea que tenga el suficiente tamaño (requiere tirar muchas lineas de codigo en varios ficheros disintos y en varios proyectos de codigo distintos) se puede dividir en algun momento del desarrollo (si nos hace falta) si el desarrollo se lleva a cabo de la siguiente manera:

                      ej) La subtarea "Gestion de BD de alumnos" de la tarea "Pagina de alta de alumnas" se desarrolla siguiendo estos pasos:

• DAO de alumnos
• DAO de cursos
• Negocio de alumnos
• Vista de alta

El programador empieza por "DAO de alumnos". ¿Como empezar? La forma correcta no empezar de cualquier manera si no definiendo el estilo que va seguir toda la implementación. Si el DAO tiene cuatro funciones mejor es definir un estilo de programacion que van a seguir las cuatro antes de empezar a picar de cualquier manera. Si se hace asi, en realidad no se tienen que picar las cuatro funciones antes de seguir con el siguiente paso, basta con picar una y el resto lo podria hacer otro programador si se da el caso que no se cumple con la planificación. El programador siempre podrá pasar al siguiente paso de la subtarea ya que otro programador podra terminar el paso anterior por él. Esto es lo que se puede llamar "empezar picando la viga":

Al picar la parte correspondiente de la viga de una subtarea, el programador ya puede pasar a la siguiente subtarea ya que los trozos que faltan los puede picar otro programador

Ojo, la parte de la viga no solo debe ser el ejemplo para implementar el resto de la subtarea. Ademas tiene que ser una parte que permita al programador pasar a la siguiente subtarea.