Pruebas unitarias. Estructura de archivo

Question

Tengo una base de código heredada de C++ con 10-15 aplicaciones, todas compartiendo varios componentes.

Al configurar pruebas de unidad para componentes compartidos y para aplicaciones mismas, me preguntaba si hay estructuras de archivos aceptadas/comunes para esto.

Dado que las pruebas de mi unidad tienen varias clases base para simplificar las configuraciones de prueba específicas del proyecto/cliente, hay una gran cantidad de archivos que son comunes para todas las pruebas.

Para mí, parece natural aquí crear un nuevo directorio que contenga todos los archivos relacionados con las pruebas, simulacros, etc., para tenerlo todo centralizado y también seguir probando definiciones relacionadas fuera de los archivos make principales.

Por otro lado, veo que es una práctica común que residan los archivos de prueba junto con los archivos de código que prueban.

¿Hay alguna manera más o menos aceptada de hacer esto?

Answer 1

Fuera de la vista, fuera de la mente; Si mantiene los archivos de prueba junto con los archivos de código, puede ser más obvio para los desarrolladores que, cuando actualicen un archivo de código, también deberían actualizar las pruebas.

Answer 2

Como mencionó, hay dos formas comunes de localizar archivos de prueba de unidades: cerca del código de implementación que están probando, y en una jerarquía de archivos separada. La elección es una cuestión de cuál es la práctica común en su organización y gusto personal.

En cuanto a la ubicación del código de prueba común, solo organice su código de prueba si organizara el código de implementación.

En su caso particular, si una infraestructura de prueba es común a varios componentes independientes, sería una buena idea crear un nuevo componente (llámelo "prueba", por ejemplo) del que otros componentes dependen para sus pruebas, en lugar de agregar dependencias entre los componentes existentes.

Answer 3

que suelen organizar dicho código en una estructura de archivos que se ve (en un caso simple) como esto:

apps 
    app1 
     app1module1 
     app2module2 
     app1tests 
    app2 
     app2module1 
     app2tests 
components 
    comp1 
     comp1module1 
     comp1module2 
     comp1tests 
common_test_stuff 

No hay una sola manera de hacer esto, pero esto parece ser una práctica común que mantiene separado el código de producción y prueba e intenta eliminar el problema fuera de la vista, (mencionado por zac) al mismo tiempo.

Answer 4

Mantenga el código de prueba cerca del código del producto, y organice su Makefile (o lo que sea que esté usando) para que las pruebas compilen al mismo tiempo que la prueba, para hacerlas visibles, especialmente si no todas las personas en el el equipo está escribiendo pruebas.