tipos - ¿Cómo se implementan pruebas unitarias en proyectos C++ a gran escala?
pruebas unitarias interfaz (9)
Creo firmemente en el uso de pruebas unitarias como parte de la construcción de grandes aplicaciones multiplataforma. Actualmente estamos planeando realizar nuestras pruebas unitarias dentro de un proyecto separado. Esto tiene el beneficio de mantener nuestra base de código limpia. Creo, sin embargo, que esto separaría el código de prueba de la implementación de la unidad. ¿Qué piensas de este enfoque y existen herramientas como JUnit para aplicaciones c ++?
Cppunit es un equivalente directo de Junit para aplicaciones C ++ http://cppunit.sourceforge.net/cppunit-wiki
Personalmente, creé las pruebas unitarias en un proyecto diferente, y creé una configuración de construcción separada que construyó todas las pruebas unitarias y el código fuente dependiente. En algunos casos, quería probar las funciones de miembro privadas de una clase, así que convertí la clase de prueba en una clase de amigo para el objeto que se probaría, pero oculté las declaraciones de amigo cuando construía en configuraciones "sin prueba" mediante declaraciones de preprocesador.
Terminé haciendo esta gimnasia de codificación ya que estaba integrando pruebas en el código heredado sin embargo. Si está comenzando con el propósito de probar la unidad, un mejor diseño puede ser simple.
Creo que está en el camino correcto con las pruebas unitarias y es un gran plan para mejorar la confiabilidad de su producto.
Aunque las pruebas unitarias no resolverán todos sus problemas al convertir su aplicación a diferentes plataformas o incluso a diferentes sistemas operativos. La razón de esto es que las pruebas de la unidad de proceso se realizan para descubrir errores en su aplicación. Simplemente arroja tantas entradas imaginables en su sistema y espera un resultado en el otro extremo. Es como conseguir que un mono golpee constantemente el teclado y observe los resultados (probadores beta).
Para llevarlo al siguiente paso, con una buena prueba de unidad necesita enfocarse en su diseño interno de su aplicación. El mejor enfoque que encontré fue el uso de un patrón de diseño o proceso de diseño llamado "programación de contrato" o "diseño por contrato". El otro libro que es muy útil para construir confiabilidad en su diseño central fue.
Depuración del proceso de desarrollo: estrategias prácticas para mantenerse enfocado, llegar a fechas de envío y formar equipos sólidos.
En nuestro equipo de desarrollo, miramos muy de cerca lo que consideramos un error de programador, error de desarrollador, error de diseño y cómo podríamos usar pruebas de unidades y también construir confiabilidad en nuestro paquete de software a través de DBC y siguiendo el consejo de depurar el desarrollo proceso.
Puede crear un proyecto de prueba unitaria para cada biblioteca en su árbol fuente en un subdirectorio de esa biblioteca. Usted termina con una aplicación de controlador de prueba para cada biblioteca, lo que hace que sea más fácil ejecutar un solo conjunto de pruebas. Al ponerlos en un subdirectorio, mantiene su base de código limpia, pero también mantiene las pruebas cerca del código.
Los scripts se pueden escribir fácilmente para ejecutar todos los conjuntos de pruebas en el árbol de origen y recopilar los resultados.
He estado utilizando una versión personalizada de la CppUnit original durante años con gran éxito, pero ahora hay otras alternativas. GoogleTest parece interesante.
Usando tut http://tut-framework.sourceforge.net/ muy simple, solo el archivo de encabezado no tiene macros. Puede generar resultados XML
Yo uso UnitTest ++. Las pruebas están en un proyecto separado, pero las pruebas reales están entrelazadas con el código real. Existen en una carpeta bajo la sección bajo prueba. es decir:
MyProject / src / <- fuente de la aplicación real
MyProject / src / tests <- la fuente de las pruebas
Si tiene carpetas anidadas (y quién no), entonces ellas también tendrán su propio subdirectorio / tests.
Hay muchos frameforks de Test Unit para C ++. CppUnit ciertamente no es el que elegiría (al menos en su versión estable 1.x, ya que carece de muchas pruebas y requiere muchas líneas de códigos redundantes). Hasta ahora, mi marco preferido es CxxTest , y planeo evaluar la fructosa algún día.
De todos modos, hay algunos "documentos" que evalúan los frameworks C ++ TU:
Debe separar su código base en una biblioteca compartida (dinámica) y luego escribir la mayor parte de las pruebas de su unidad para esta biblioteca.
Hace dos años (2008) participé en un gran proyecto de Infraestructura LSB implementado por The Linux Foundation. Uno de los objetivos de este proyecto fue escribir pruebas unitarias para 40,000 funciones de las bibliotecas centrales de Linux. En el contexto de este proyecto, hemos creado la tecnología AZOV y la herramienta básica denominada API Sanity Autotest para generar automáticamente todas las pruebas. Puede intentar usar esta herramienta para generar pruebas unitarias para su (s) biblioteca (s) base.
Ese es un enfoque razonable.
He tenido muy buenos resultados tanto con UnitTest ++ como con Boost.Test
He visto CppUnit, pero para mí, se sentía más como una traducción de las cosas JUnit que algo dirigido a C ++.
Actualización: en estos días prefiero usar Catch . Encontré que es efectivo y simple de usar.