¿Cómo ejecutas las pruebas de tu unidad? Banderas del compilador? Bibliotecas estáticas?

Question

Estoy empezando con TDD y tengo curiosidad acerca de qué enfoques toman los demás para ejecutar sus pruebas. Como referencia, estoy usando el marco de prueba de google, pero creo que la pregunta es aplicable a la mayoría de los otros frameworks de prueba y a otros lenguajes que no sean C/C++.

Mi enfoque general hasta ahora ha sido la de hacer una de tres cosas:

1. Escribe la mayoría de la aplicación en una biblioteca estática, a continuación, crear dos archivos ejecutables. Un ejecutable es la aplicación en sí, mientras que el otro es el corredor de prueba con todas las pruebas. Ambos enlazan a la biblioteca estática.

2. Incruste el código de prueba directamente en la propia aplicación y habilite o deshabilite el código de prueba utilizando indicadores de compilación. Este es probablemente el mejor enfoque que he usado hasta ahora, pero desordena el código un poco.

3. Incruste el código de prueba directamente en la propia aplicación y, dados ciertos modificadores de línea de comandos, ejecute la aplicación o ejecute las pruebas integradas en la aplicación.

Ninguna de estas soluciones son particularmente elegante ...

¿Cómo que lo hace?

Answer 1

Tiendo a favorecer libs estáticas sobre dlls así que la mayoría de mi código C++ termina en libs estáticos de todos modos y, como has encontrado, son tan fáciles de probar como dlls.

Para el código que se integra en un exe tengo un proyecto de prueba separado que simplemente incluye los archivos fuente que están bajo prueba y que generalmente están integrados en el exe O construyo una nueva lib estática que contiene la mayor parte del exe y prueba eso de la misma manera que pruebo todas mis otras librerías estáticas. Encuentro que, por lo general, tomo el enfoque de "la mayoría del código en una biblioteca" con nuevos proyectos y el enfoque "extraiga los archivos de origen del proyecto exe en el proyecto de prueba" cuando estoy adaptando las pruebas a las aplicaciones existentes.

No me gustan sus opciones 2 y 3 en absoluto. Administrar las configuraciones de compilación para 2 es probablemente más difícil que tener un proyecto de prueba separado que simplemente atraiga las fuentes que necesita e incluir todas las pruebas en el exe como sugiere en 3 es simplemente incorrecto;)

Answer 2

Estoy usando una prueba de terceros corredores con su marco de trabajo y que incluyen pruebas en el script de compilación. Las pruebas están fuera del código de producción (dll externo).

Answer 3

Su enfoque no. 1 es la forma en que siempre lo hice en C/C++ y Java. La mayor parte del código de la aplicación está en la biblioteca estática y trato de mantener al mínimo la cantidad de código adicional necesario para la aplicación.

La forma en que abordo TDD en Python y otros lenguajes dinámicos es ligeramente diferente, ya que dejo el código fuente para la aplicación y las pruebas por ahí y un corredor de prueba encuentra las pruebas y las ejecuta.

Answer 4

Uso dos enfoques, para dlls Acabo de vincular mis pruebas de unidad con el dll, fácil. Para los archivos ejecutables, incluyo los archivos fuente que se están probando tanto en el proyecto ejecutable como en el proyecto de prueba de la unidad. Esto aumenta ligeramente el tiempo de compilación, pero significa que no necesito separar el ejecutable en una lib estática y una función principal.

Utilizo boost.test para pruebas unitarias y cmake para generar mis archivos de proyecto y encuentro que este es el enfoque más fácil. También estoy introduciendo lentamente pruebas unitarias a una gran base de códigos heredados, por lo que intento introducir la menor cantidad de cambios, en caso de que cause inconvenientes a otros desarrolladores y los desanime de las pruebas unitarias. Me preocuparía que el uso de una biblioteca estática solo para pruebas unitarias pueda verse como una excusa para no adoptarlo.

Habiendo dicho esto, creo que el enfoque de la biblioteca estática es bueno, especialmente si está empezando desde cero.

Answer 5

Para las aplicaciones de C/C++ trato de tener la mayor cantidad de código posible en uno o más dlls, con la aplicación principal como mínimo para iniciar y transferir a la dll. Los Dlls son mucho más fáciles de probar porque pueden exportar tantos puntos de entrada como quiera para que una aplicación de prueba los use.

Uso una aplicación de prueba separada que enlaza con el Dll (s).Estoy totalmente a favor de mantener el código de prueba y el código de "producto" en módulos separados.

Answer 6

voy con # 1, algunas de las razones son

• Permite comprobar que cada enlaces lib correctamente
• Usted no quieren código extra en el producto
• Es más fácil para depurar persona pequeña programas de prueba
• Se pueden necesitar varios ejecutables para algunas pruebas (como pruebas de comunicación)

para C++ construir y prueba, Me gusta usar CMake, que puede ejecutar una selección de los ejecutables de destino como pruebas e imprimir un resumen de los resultados.

Answer 7

Personnally, yo uso otro enfoque que depende un poco del suyo:

Mantengo intacto el proyecto a prueba. Si es un ejecutable, debe seguir siendo un ejecutable. Simplemente crea una acción posterior a la compilación para agregar todos los archivos obj a una biblioteca estática.

Luego, puede crear su proyecto de prueba, vinculando el marco de prueba y su biblioteca estática previamente generada.

Éstos son algunos de los temas correspondientes a su pregunta:

• Visual Studio C++: Unit test exe project with google test?
• Linker error - linking two "application" type projects in order to use Google Test