Hace tiempo estaba buscando una explicación detallada acerca de lo que son las «smoke tests» o pruebas de humo, encontré un artículo en wikipedia y de ahí un enlace a una muy buena publicación de Steve Mconnell , que me puse a traducir y la escribo a continuación:
Build diario y pruebas de humo
Si quieres crear un programa de computadora sencillo que consista de un solo archivo, solamente necesitaras compilar y enlazar ese único archivo. En un típico proyecto en equipo, que involucra docenas, cientos e incluso miles de archivos, sin embargo, el proceso de crear un programa ejecutable se vuelve mas complicado y requiere más tiempo. Se debe “construir” el programa a partir de cada uno de sus componentes.
Una practica común en Microsoft y algunas otras grandes compañias de software es el proceso llamado “construcción diaria y pruebas de humo” (daily build and smoke test). Cada archivo es compilado, enlazado y combinado en un programa ejecutable cada día, el programa es entonces sometido a unas pruebas llamadas «smoke test» una revisión relativamente simple para ver si el programa “humea” cuando corre.
Beneficio
Este simple proceso produce muchos significativos beneficios:
Minimiza riesgos de integración. Uno de los mayores riesgos a los que un proyecto en equipo se enfrenta es que cuando los diferentes miembros del equipo combinan o «integran» el código, han estado trabajando en el separadamente, el código resultante no funciona bien. Dependiendo de que tan tarde en el proyecto la incompatibilidad es descubierta, depurarlo puede tomar mas tiempo de lo que habría tomado si la integración hubiera ocurrido en una etapa mas temprana, las interfaces del programa pueden requerir cambios, o componentes mayores del sistema tienen que ser rediseñados y reimplementados. En casos extremos, los errores de integración han causado la cancelación de proyectos. El proceso de construcción diaria y pruebas de humo mantiene errores de integración pequeños y manejables, además de que previene problemas de integración durante el uso del software.
Reduce el riesgo de tener baja calidad. Relacionado al riesgo de integraciones problemáticas o no exitosas esta el riesgo de baja calidad. Al realizar mínimas pruebas de humo de todo el código diariamente, se previene que los problemas de calidad tomen control del proyecto. Se lleva el sistema a un estado correcto conocido se mantiene ahí. Simplemente no permite el deterioro al punto donde los problemas que más tiempo consumen puedan ocurrir.
Ayuda a facilitar el diagnostico de defectos. Cuando el producto es construido y compilado diariamente, es fácil encontrar el por qué de un defecto en un día determinado, si el producto funciona el día 17 y falla el día 18, obviamente algo que sucedió entre ambos builds provocó la falla.
Aumenta la moral. Ver funcionar un producto, aumenta increíblemente la moral, casi sin importar lo que el producto haga. Los desarrolladores pueden estar emocionados por el simple hecho de que se muestra un rectángulo! Con los builds diarios, un poco más del producto funciona cada día, y eso mantiene la moral en alto.
Usando el build diario y las pruebas de humo
La idea detrás de este proceso es simplemente construir el producto y probarlo cada día. Los siguientes son algunas prácticas de lo que se debe y no se debe hacer con esta simple idea:
Construir diariamente. La parte más fundamental del build diario es el hecho de ser «diario». como lo menciona Jim McCarthy (Dynamics of Software Development, Microsoft Press, 1995), trata el build diario como si fuera el latido del corazón del proyecto. Si no hay latidos, el proyecto esta muerto. Un poco menos metaforicamente, Michael Cusumano y Richard W. Selby describen el build diario como el “pulso sincronizado de un proyecto” (Microsoft Secrets, The Free Press, 1995). Esta permitido que el código de diferentes desarrolladores se encuentre un poco fuera de sincronizacion entre los pulsos, pero cada vez que hay un pulso de sincronización, el código debe volver a su alineación. Cuando insistes en mantener esos pulsos cercanos entre si previenes que los desarrolladores estén totalmente fuera de sincronización.
Algunas organizaciones construyen cada semana en vez de cada día. El problema es que si el build está roto una semana, pueden pasar varias semanas antes del siguiente build funcional. Cuando eso pasa, pierdes virtualmente todos los beneficios de construir frecuentemente.
Revisar builds rotos. Para que funcione el proceso del daily-build, el software que construye debe funcionar. Si el software no es utilizable, el build es considerado como roto y repararlo se vuelve en la mayor prioridad.
Cada proyecto establece su propio estándar para lo que constituye «romper el build». El estandar necesita establecer un nivel de calidad suficientemente estricto para evitar defectos que eviten la ejecución del programa pero suficientemente permisivo como para ignorar defectos triviales a los que se les dedicaría atención innecesaría que paralizaría el progreso.
Como minimo, un «buen» build deberia:
• Compilar todos los archivos, librerias, y otros componentes exitosamente;
• Enlazar todos los archivos, librerias, y otros componentes exitosamente;
• No contener defectos que eviten la ejecución del programa o que haga peligrosa su operacion; y
• pasar las pruebas de humo.
Smoke test diarias. Las pruebas de humo deberían probar el sistema completo principio a fin. No necesitan ser muy exhaustivas, pero sí capaces de revelar problemas mayores. Las smoke tests deben ser suficientes para que si el build las pasa, se pueda asumir que es lo suficientemente estable para ser probado con mayor detalle.
El build diario tiene poco valor sin las pruebas de humo, ya que estas son el centinela que protege contra el deterioro de la calidad del producto y de repugnantes problemas de integración. Sin ellas, el build diario se convierte en una pérdida de tiempo si se pretende asegurar que se tiene un build limpio todos los días.
Las smoke test deben involucrar lo que el sistema involucra. Al principio, las smoke probablemente probarán algo simple, como que el sistema pueda decir, «Hola, mundo.» Conforme el sistema se desarrolla, las smoke test se volverán más extensas. La primera prueba puede tomar algunos segundos en ser ejecutada; conforme el systema crece, las smoke test pueden crecer a 30 minutos, una hora, o mas.
Establecer un equipo para el build. En la mayoría de los proyectos, tender a mantener el build y las smoke test al dia se vuelve una tarea lo auficientemente grande como para ser una parte explicita del trabajo de alguien. En proyectos grandes, llega a ser un trabajo de tiempo completo para más de una persona. En Windows NT 3.0, por ejemplo, habia 4 personas dedicadas de tiempo completo a esto (Pascal Zachary, Showstopper!, The Free Press, 1994).
Agregar revisiones al build solo cuando tenga sentido hacerlo. Un solo desarrollador usualmente no escribe código de lo suficientemente rápido como para agregar cambios significativos al código diariamente. Ellos deberían trabajar en un fragmento de código e integrarlo cuando tienen una colección de código en un estado consistente, usualmente una vez en varios días.
Crear penalización por romper el build. Muchos de los grupos que utilizan daily builds crean penalizaciones por romper dicho build. Deje en claro desde el principio que mantener la integridad del build es la mayor prioridad del proyecto. Un build roto deberìa ser la excepción, no la regla. Insista en que los desarrolladores que han roto el build dejen todos los demás trabajos hasta que hayan corregido el error. Si el build se rompe con mucha frecuencia, es difícil tomar seriamente el trabajo de mantenerlo sin fallas.
Una penalizacion amable puede ayudar a enfatizar esta prioridad. Algunos grupos dan paletas a cada «mamón» que rompe el build. Este desarrollador debe pegar esta paleta en la ventana de su oficina hasta que arregle el problema. Otros gupos tienen desarrolladores culpables que usan cuernos de cabra o contribuyen $5 a un fondo para la moral (Para comprar cafè o el almuerzo).
Algunos proyectos establecen una penalización más severa. Los desarrolladores de Microsoft que trabajan en proyectos de perfil alto perfil como Windows NT, Windows 95, y Excel han tenido que usar radio localizadores en las últimas etapas de sus proyectos. Si alguno rompe el build, son llamados a reparar los defectos aún cuando estos sean encontrados a las 3 a.m.
Construir y probar aun bajo presión. Cuando la presion del calendario se vuelve intensa, el trabajo requerido para mantener el build diario puede parecer una perdida de tiempo extravagante. La realidad es lo contrario. Bajo estrés, los desarrolladores pierden un poco de su disciplina. Sienten la tentación de tomar atajos en el diseño y la implementación que no tomarían en circunstancias menos estresantes. Ellos revisan y prueban unitariamente (unit-test) su propio código con menor cuidado que lo usual. El código tiende entonces a un estado de entropía mas rápido de lo que lo haría en tiempos de menor tensión.
En este contexto, el build diario refuerza la disciplina y mantiene en movimiento los proyectos con mayor presión. El código aún tiende hacia un estado de entropía, pero el proceso de construcción lleva esa tendencia mas abajo cada día.
¿Quién puede beneficiarse de este proceso
Algunos desarrolladores alegan que no es práctico construir todos los días porque sus proyectos son demasiado grandes. Pero el que fue quizás el proyecto de software más complejo en la historia reciente utilizó correctamente el build diario. En el momento en que fue lanzado, Microsoft Windows NT 3.0 consistía de 5,6 millones de líneas de código repartidas a través de 40.000 archivos de código fuente. Una construcción completa tomó hasta 19 horas en varias máquinas, pero el equipo de desarrollo de NT se las arregló para construir todos los días (Zachary, 1994). Lejos de ser una molestia, el equipo de NT atribuyó gran parte de su éxito en ese gran proyecto a los builds diarios. Aquellos de nosotros que trabajamos en proyectos de proporciones menos asombrosas menos tendrán un momento difícil al tratar de explicar por qué no habríamos también de aprovechar los beneficios de esta práctica.