Ciclo de Trabajo de Codice Software III: Test

Ciclo de Trabajo de Codice Software III: Test

9:18 0 Comments

En el capítulo anterior, os he mostrado las herramientas de trabajo.
En esta ocasión os voy a enseñar la parte del ciclo de trabajo de cada uno de los desarrolladores de Plastic SCM, correspondiente a los test.

Testear cada rama

Durante el desarrollo de una tarea, la persona del equipo encargada de llevarla a cabo pasaba una serie de test en su rama. Esto lo puede hacer al finalizar el desarrollo de la tarea o las veces que quiera mientras la está haciendo.
Hay tres tipos de test, que se mantienen entre todo el equipo:

• Test Unitarios: realizados en NUNIT, son rápidos y efectivos.
• Test de Línea de Comandos: permiten probar la parte Interfaz de Línea de Comandos (CLI ) de Plastic SCM. Hay cerca de 400 tests, y cada uno tarda un mínimo de 5 segundos por test. Prueban el sistema end-to-end. Desde hace más de un año, están intentando rebajar el número de tests de este tipo y aumentar los tests unitarios, pero durante mucho tiempo han sido el centro del sistema de pruebas y un salvavidas. El mayor inconveniente es el tiempo de ejecución: un juego completo puede tardar casi 50 minutos o 1 hora en una máquina "normal".
• Test GUI (Graphical User Interface): en esta parte utilizan test complete. Hay más de 250 tests para la parte de interfaz gráfica. Estos test, se ejecutan por cada tarea, pero lo hacen en una máquina virtual, porque hacerlo en tu propia máquina significa quedarte sin control: se apoderan de ratón y teclado.

Al realizar esta parte, lanzar los test en la máquina de cada desarrollador, se han encontrado con que:

• Ralentizan el trabajo: ya he comentado que los tests de GUI, pueden llegar a bloquear la máquina.
• Saltar esta fase: es fácil hacerlo, pensando esto no falla seguro.
• No hay log de registro: cada uno tiene la responsabilidad de hacerlo. Saben que las pruebas que no hagan se las pasan a la persona responsable de los merges, porque nada se queda sin probar.

Conclusión

Tenían que lograr pasar los test sobre cada tarea de forma controlada.

Esto lo han conseguido con Bamboo (Atlassian) empleando, a qué no lo adivinas?... pues sí "Rama por Tarea".

 El proceso de trabajo es el siguiente:

1. Bamboo escucha con los scripts de Plastic SCM hasta que encuentra una rama con el atributo "status" colocado a "finish"
2. Cambia el estado a "testing"
3. Utilizando el update de Plastic SCM, optimizado para bajar sólo lo que ha cambiado desde el punto anterior que tuviera Bamboo, baja el código de la rama.
4. Compila, si falla lanzará un error.
5. Pasa FXCop buscando nuevos fallos.
6. Pasa tests unitarios.
7. Pasa Smoke Test, los test para la parte de Interfaz de Linea de Comandos (CLI)
8. Pasa los test GUI, para la parte gráfica.

Si todos los tests han ido bien y no han lanzado error, la rama se pasa a estado "tested" y se va a por la siguiente rama.
Ahora el proceso es fantástico, se pasan los test de Bamboo en Windows y en Linux en paralelo.