Agregar pruebas unitarias a un proyecto existente

Question

Mi pregunta es bastante relevante para something asked before pero necesito algunos consejos prácticos.

Tengo "Trabajo de forma efectiva con código heredado" en mis manos y estoy usando el consejo del libro mientras lo leo en el proyecto en el que estoy trabajando. El proyecto es una aplicación C++ que consta de algunas bibliotecas, pero la mayor parte del código se compila en un único 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 código mientras no puedo extraer el código de mi aplicación "undertest" a un biblioteca. En este momento, he realizado mi proceso de compilación para la aplicación que contiene el enlace de prueba de la unidad contra los archivos de objeto generados a partir del proceso de compilación de la aplicación principal, pero realmente no me gusta. ¿Hay alguna sugerencia?

Answer 1

Si la aplicación de prueba solamente es la vinculación del objeto los archivos 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 la de prueba. Si no puedes, entonces no veo que lo que estás haciendo sea una mala alternativa.

Si tiene que vincular otros archivos de objetos que no se prueban, es un signo de dependencias que deben romperse, para lo cual tiene el libro perfecto. Tenemos problemas similares y usamos un sistema como el sugerido por Vlion

Answer 2

Working Effectively With Legacy Code es el mejor recurso para comenzar a probar el código anterior. Realmente no hay soluciones a corto plazo que no empeoren las cosas.

Answer 3

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 prueben al mismo tiempo (dos binarios resultantes de la misma base de código). Sí, huele a pescado, pero es muy práctico.

Felicidades a usted y buena suerte con su prueba.

Answer 4

Prefiero un ejecutable de prueba por prueba. Esto permite las uniones de tiempo de enlace y también permite 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. Esperemos que esto signifique que sus pruebas solo se ejecuten cuando el código realmente cambie.

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

Answer 5

Voy a esbozar una estructura makefile puede utilizar:

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 un único desarrollador en mi proyecto