Agregando pruebas unitarias a un proyecto existente

Question

Mi pregunta es bastante relevante para algo preguntado antes pero necesito algunos consejos prácticos.

Tengo " Trabajando efectivamente con el código heredado " en mis manos y estoy usando los consejos del libro mientras lo leo en el proyecto en el que estoy trabajando. El proyecto es una aplicación de C ++ que consta de unas pocas bibliotecas, pero la mayor parte del código se compila en un solo ejecutable. Estoy usando Googletest para agregar pruebas unitarias al código existente cuando tengo que tocar algo.

Mi problema es cómo puedo configurar mi proceso de compilación para poder construir mis pruebas unitarias, ya que hay dos ejecutables diferentes que necesitan compartir el código mientras no puedo extraer el código de mi " prueba; " Aplicación a una biblioteca. Ahora mismo he realizado mi proceso de compilación para la aplicación que contiene el enlace de pruebas unitarias contra los archivos de objetos generados a partir del proceso de compilación de la aplicación principal, pero realmente no me gusta. ¿Hay alguna sugerencia?

Answer 1

Si su aplicación de prueba solo está vinculando los archivos de objetos que necesita probar, entonces ya los está tratando como una biblioteca, debería ser posible agrupar esos archivos de objetos en una biblioteca separada para la aplicación principal y de prueba. Si no puedes, entonces no veo que lo que estás haciendo sea una alternativa demasiado mala.

Si tiene que vincular otros archivos de objetos que no están bajo prueba, entonces es un signo de dependencias que deben romperse, para lo cual tiene el libro perfecto. Tenemos problemas similares y utilizamos un sistema como el sugerido por Vlion

Answer 2

Trabajar de manera efectiva con el código heredado es el mejor recurso para comenzar Prueba de código antiguo. Realmente no hay soluciones a corto plazo que no hagan que las cosas empeoren.

Answer 3

Dibujaré una estructura de makefile que puedes usar:

all: tests executables

run-tests: tests
    <commands to run the test suite>

executables: <file list>
    <commands to build the files>

tests: unit-test1 unit-test2 etc

unit-test1: ,files that are required for your unit-test1>
    <commands to build unit-test1>

Eso es más o menos lo que hago, como desarrollador único en mi proyecto

Answer 4

Personalmente, continuaría haciendo lo que está haciendo o consideraría tener un script de compilación que haga que la aplicación de destino y la unidad se prueben al mismo tiempo (dos binarios resultantes del mismo código base). Sí, huele a pescado pero es muy práctico.

Felicitaciones a usted y buena suerte con sus pruebas.

Answer 5

Prefiero un ejecutable de prueba por prueba. Esto permite costuras de tiempo de enlace y también ayuda a permitir TDD, ya que puede trabajar en una unidad y no preocuparse por el resto de su código.

Hago que las bibliotecas dependan de todas las pruebas. Con suerte, esto significa que sus pruebas solo se ejecutan cuando el código realmente cambia.

Si obtiene un error, las pruebas interrumpirán el proceso de compilación en el lugar correcto.