- Esta pregunta no es ni acerca de los marcos de prueba de unidades.
- Esta pregunta es no sobre la escritura de Pruebas Unitarias.
- Esta pregunta es sobre donde para colocar el código UT escrito y cómo / cuándo / dónde compilarlo y ejecutarlo.
En Trabajando de manera efectiva con el código heredado , Michael Feathers afirma que
buenas pruebas unitarias ... corre rápido
y eso
Una prueba de unidad que tarda 1/10 de segundo en ejecutarse es una prueba de unidad lenta.
Creo que estas definiciones tienen sentido. También creo que implican que debes mantener un conjunto de Pruebas de unidad y un conjunto de Esas pruebas de código que demoran más por separado, pero creo que esa es la el precio por el que solo paga una prueba de unidad si se ejecuta (muy) rápidamente.
Obviamente, el problema en C ++ es que para "ejecutar" su prueba de unidad ( s ), debe:
- Edite su código (producción o prueba de unidad, según el "ciclo" en el que se encuentre)
- compilar
- enlace
- Ejecutar prueba de unidad ejecutable ( s )
Editar (después de una votación cerrada extraña) : antes de entrar en los detalles, intentaré resumir el punto aquí:
¿Cómo puede organizarse efectivamente el código de prueba unitaria de C ++, de modo que sea eficiente editar el código (de prueba) y ejecutar el código de prueba?
El problema primero es decidir dónde colocar el código de prueba de unidad para que:
- es "natural" editarlo y verlo en combinación con el código de producción asociado.
- es fácil / rápido comenzar el ciclo de compilación para la unidad su cambio actual
El segundo problema relacionado es, entonces, lo que debe compilarse para que la retroalimentación sea instantánea.
Opciones extremas:
- Cada Unidad-Prueba-Prueba-Unidad vive en un archivo cpp separado y este archivo cpp se compila + se vincula por separado (junto con el archivo de unidad de código fuente que prueba) a un solo ejecutable que luego ejecuta esta prueba de unidad.
- (+) Esto minimiza el tiempo de inicio (compilación + enlace!) para la única unidad de prueba.
- (+) La prueba se ejecuta súper rápido, porque solo prueba una unidad.
- (-) La ejecución de toda la suite deberá iniciar un montón de procesos. Puede ser un problema para gestionar.
- (-) La sobrecarga del inicio del proceso se hará visible
- El otro lado sería tener - aún - un archivo cpp por prueba, pero todos los archivos cpp de prueba (¡junto con el código que prueban!) están vinculados en un ejecutable (por módulo / proyecto / elija su elección).
- (+) El tiempo de compilación aún estaría bien, ya que solo se compilará el código modificado.
- (+) La ejecución de toda la suite es fácil, ya que solo hay que ejecutar un archivo.
- (-) La suite tardará años en enlazarse, ya que cada recompilación de cualquier objeto activará un nuevo enlace.
- (-) (?) La demanda demorará más en ejecutarse, aunque si todas las pruebas unitarias son rápidas, el tiempo debería estar bien.
Entonces, ¿cómo se manejan las pruebas unitarias de C ++ en el mundo real ? Si solo ejecuto esas cosas cada noche / hora, la segunda parte realmente no importa, pero la primera parte, a saber, cómo "acoplar" el código UT al código de producción, de modo que es "natural" que los desarrolladores mantengan ambos en El enfoque siempre importa, creo. (Y si los desarrolladores tienen el código UT en foco, querrán ejecutarlo, lo que nos lleva de nuevo a la segunda parte).
¡Historias y experiencias del mundo real apreciadas!
Notas:
- Esta pregunta deja intencionalmente la plataforma no especificada y el sistema make / project.
- Preguntas etiquetadas UT & C ++ es un buen lugar para comenzar, pero desafortunadamente muchas preguntas, y especialmente las respuestas, están demasiado centradas en los detalles o en marcos específicos.
- Hace un tiempo, respondí a pregunta similar sobre la estructura para pruebas de unidades de impulso. Me parece que esta estructura carece de pruebas de unidad "reales" y rápidas. Y encuentro la otra pregunta demasiado estrecha, de ahí esta nueva pregunta.