unidad de prueba de compilación de los archivos de

Question

¿Cuáles son las mejores políticas para la unidad de pruebas de construir archivos?

La razón que pido es que mi empresa produce altamente confiable dispositivos embebidos.Revisiones de Software no son sólo una opción, ya que le costo a nuestros clientes a miles de personas para distribuir.Debido a esto tenemos muy estricto código de procedimientos de calidad(unidad de pruebas, revisiones de código, trazabilidad, etc).Esos procedimientos se aplican a nuestros archivos de construcción (autotools si usted debe conocer, espero que lástima), pero si se siente como un hack.

Uh...el proyecto se compila...marca los archivos de construcción como se ha revisado y unidad de la prueba.

Tiene que haber una mejor manera.Ideas?

Answer 1

Aquí es el enfoque que hemos tomado cuando la construcción de una gran base de código (muchos millones de líneas de código) a través de más de una docena de plataformas.

• Makefile los cambios son revisados por el equipo de construcción. Estas personas se conocen los errores de la gente tiende a hacer en nuestro entorno, y ellos son los que sienten el peso de cuando una generación se rompe, por lo que están motivados para encontrar problemas.
• Minimizar lo que debe ir en un archivo Makefile, por lo que hay menos posibilidades de error.Tenemos una capa en la parte superior de hacer, que genera el fichero Makefile.Un desarrollador sólo tiene que indicar en el nivel superior del archivo, el uso de etiquetas, que, por ejemplo, un objetivo es una biblioteca compartida o una unidad de prueba.Generalmente un objetivo se define en una línea, que luego se traduce en múltiples ajustes/objetivos en el Makefile generados.Algo Similar se podría hacer con las herramientas de generación como scons que permiten abstraen cosas como plataforma de detalles específicos, haciendo que los objetivos muy simple.
• Unidad de pruebas de nuestra herramienta de construcción. La herramienta está escrito en Perl, así que el uso de Perl Test::More marco de pruebas unitarias de allí para comprobar que la herramienta genera el correcto Makefile dado nuestro alto nivel de archivo.Si usamos algo como scons lugar, yo uso la su marco de pruebas.
• Unidad de pruebas de nuestro nightly build/secuencias de comandos de prueba. Tenemos un conjunto de scripts de inicio de todas las noches se construye en cada plataforma, ejecute las herramientas de análisis estático, ejecución de la unidad de pruebas, ejecución de pruebas funcionales, y el informe de todos los resultados a una base de datos central.Ponemos a prueba las distintas secuencias de comandos de forma individual, sobre todo el uso de la shunit2 marco de pruebas unitarias para sh/bash/ksh/etc.
• De extremo a extremo de las pruebas de nuestra generación/pruebas de proceso. Estoy trabajando en un extremo-a-extremo de prueba que funciona sobre un pequeño árbol de código fuente en lugar de nuestro código de la producción, ya que este último puede tomar horas para construir.Estas pruebas están orientados principalmente a la verificación de que nuestros destinos de compilación todavía el trabajo y los resultados del informe en nuestra base de datos central, incluso después de, por ejemplo, la actualización de nuestra herramienta de cobertura de código o haciendo cambios en nuestros scripts.

Answer 2

Haga que su fichero de construcción para compilar una versión conocida de su software (o un pedazo más simple de código que es similar desde una perspectiva de construcción) y comparar el resultado obtenido con sus nuevas herramientas de construcción a un resultado esperado (construido con una versión validada de las herramientas de construcción).

Answer 3

En mis proyectos acumulación de archivos no cambian muy a menudo. Aún más, puedo reutilizar las acumulaciones de archivos de proyectos anteriores, cambiando sólo algunas variables (que me mudé a una fácil reconocer sección). Es por eso que para mí es que no sean necesarios a la unidad de prueba de las acumulaciones de archivos. Eso puede ser diferente en otros proyectos.