archivos de compilación de prueba unitaria

Question

¿Cuáles son las mejores políticas para probar unidades de archivos de compilación?

La razón por la que pregunto es por qué mi empresa produce dispositivos integrados altamente confiables. Los parches de software simplemente no son una opción, ya que a nuestros clientes les cuesta miles distribuirlos. Debido a esto, tenemos procedimientos de calidad de código muy estrictos (pruebas unitarias, revisiones de códigos, trazabilidad, etc.). Esos procedimientos se están aplicando a nuestros archivos de compilación (autotools si usted debe saber, espero piedad), pero si se siente como un truco.

Uh ... el proyecto compila ... marque los archivos de compilación como revisados ​​y probados en unidades.

Tiene que haber una manera mejor. Ideas?

Answer 1

Este es el enfoque que hemos tomado al construir una gran base de código (muchos millones de líneas de código) en más de una docena de plataformas.

• cambios Makefile son revisados ​​por el equipo de construcción. Estas personas conocen los errores que las personas tienden a cometer en nuestro entorno de compilación, y son ellos quienes sienten la peor parte cuando se rompe una compilación, por lo que están motivados para encontrar problemas.
• Minimice lo que necesita ir en un Makefile, por lo que hay menos oportunidades de error. Tenemos una capa encima de make, que genera el Makefile. Un desarrollador solo tiene que indicar en el archivo de nivel superior, usando etiquetas, que, por ejemplo, un objetivo determinado es una biblioteca compartida o una prueba unitaria. Por lo general, un objetivo se define en una línea, que luego da como resultado múltiples configuraciones/objetivos en el archivo Makefile generado. Se podrían hacer cosas similares con las herramientas de compilación como scons que permiten abstraer detalles como detalles específicos de la plataforma, lo que hace que los objetivos sean muy simples.
• Pruebas unitarias de nuestra herramienta de compilación. La herramienta está escrita en Perl, por lo que usamos el marco de prueba de la unidad Test::More de Perl para verificar que la herramienta genera el archivo Makefile correcto dado nuestro archivo de nivel superior. Si usáramos algo así como scons en su lugar, usaría their testing framework.
• Pruebas unitarias de nuestros scripts de creación/prueba nocturnos. Tenemos un conjunto de scripts que inician compilaciones nocturnas en cada plataforma, ejecutan herramientas de análisis estático, ejecutan pruebas unitarias, ejecutan pruebas funcionales e informan todos los resultados a una base de datos central. Probamos las distintas secuencias de comandos de forma individual, principalmente utilizando el marco de pruebas de unidades shunit2 para sh/bash/ksh/etc.
• Pruebas de extremo a extremo de nuestro proceso de compilación/prueba. Estoy trabajando en una prueba de extremo a extremo que opera en un pequeño árbol fuente en lugar de en nuestro código de producción, ya que este último puede tardar horas en construirse. Estas pruebas están principalmente dirigidas a verificar que nuestros objetivos de construcción sigan funcionando e informe los resultados en nuestra base de datos central incluso después de, por ejemplo, actualizar nuestra herramienta de cobertura de código o realizar cambios en nuestros scripts de compilación.

Answer 2

En mis proyectos, los archivos de compilación no cambian muy a menudo. Aún más, puedo reutilizar archivos de compilación de proyectos anteriores, solo cambiando algunas variables (que moví a una sección fácil de reconocer). Es por eso que para mí no es necesario probar los archivos de construcción. Eso puede ser diferente en otros proyectos.

Answer 3

Tenga su archivo de compilación para compilar una versión conocida de su software (o una pieza de código más simple que sea similar desde una perspectiva de compilación) y compare el resultado obtenido con sus nuevas herramientas de compilación con un resultado esperado (construido con una versión validada de las herramientas de compilación).