Eclipse y su infraestructura de testing

Hace tiempo hablaba del Eclipse Way y de como me fascina el proceso de desarrollo que siguen.

Repasando un ppoco las charlas de este año de la EclipseCon 2007 (ya ha llovido) me he encontrado con una bastante interesante de Sonia Dimitrov y Kim Moir donde hablaron sobre todo el proceso de QA que se sigue en Eclipse.



Se extraen varias cosas interesantes:

• Tienen el rol de build engineer para proteger a los desarrolladores del proceso de build (este rol merece un post en si mismo).
• 176.000 tests en 33.000 JUnit tests ejecutándose en cinco build machines con máquinas virtuales 1.4, 1.5 y 1.6.
• 469 tests de rendimiento con 2345 tests que se ejecutan en cinco máquinas diferentes. Se ejecutan sólo unos cuantos días debido a que lleva unas 10 horas ejecutar los tests y procesar los resultados.
• Para asegurarse la validez de los tests de rendimiento utilizan imágenes ghost que instalan justo antes de lanzar los tests.
• Tienen un conjunto de tests de limpieza. Chequean que todo esté correcto: javadocs, licencias, políticas de código, etc.
• Los desarrolladores escriben test unitarios, pero el código de los tests se mantiene separado en un CVS propio.
• Los resultados de los tests de rendimiento se almacenan en una base de datos dedicada.
• Para detectar fallos tienen un parser que analiza la salida de los tests y en caso de errores genera reportes y los envia a una lista de correo.
• La mayor parte de los errores que obtienen no se deben en realidad a errores en el código sino a problemas con las máquinas, poco espacio en disco, actualizaciones de software, antivirus, etc.

No sé que os parece, pero a mi me ha sorprendido especialmente toda la infraestructura dedicada al testing, incluido el dedicar un CVS específicamente para el almacenar el código de los tests. Está claro que toda esta infraestructura y este proceso tan elaborado debe tener algo que ver con la capacidad para estar lanzando versiones sin retraso durante cinco años.