Marco de pruebas unitarias de C++ [cerrado]

Criterios de comparación del marco de pruebas unitarias

Debe tener en cuenta los siguientes criterios importantes para comparar marcos de trabajo de pruebas unitarias de C++:

1. Compatibilidad : si el marco se compila con su proyecto. Es posible que esté utilizando opciones como -fno-rttiy algunos marcos y luego no se puedan compilar.
2. Facilidad de uso : cuánto trabajo es escribir una prueba. C ++ no tiene reflexión, por lo que los marcos deben resolver el registro de prueba de alguna manera.
3. Características : ¿puede hacer lo que necesita que haga? Según una publicación en Google Testing Blog , la mayoría de los marcos tienen las características necesarias y difieren principalmente en los puntos 1 y 2.
4. Popularidad y familiaridad : si las personas conocen el marco. Esto es importante especialmente para el software libre, para no limitar la base de colaboradores potenciales.

Marcos populares y sus medidas de popularidad

Para medir la popularidad, podría ser suficiente buscar Stack Overflow y GitHub . Las siguientes estadísticas se recopilaron en enero de 2016 y es posible que cambien drásticamente con el tiempo; además, las tendencias, que no se presentan aquí, pueden ser más importantes que los números absolutos.

Marcos populares de Stackoverflow

Una búsqueda de [unit-testing] [c++] encuentra 1211 preguntas sobre SO. Buscando marcos individuales, encontramos:

• Prueba de Google : 857 preguntas (término de palabra clave [googletest])
• CppUnit : 203 preguntas (término de palabra clave [cppunit])
• Captura : 12 preguntas (término de palabra clave [catch-unit-test])

Frameworks populares de GitHub

En GitHub hay alrededor de 461 000 repositorios para la consulta "idioma: C++".

GitHub:

• Prueba de Google : 1 870 016 archivos C++ (término de búsqueda "include gtest.h":)
• CppUnit : 297 525 archivos C++ (término de búsqueda "include cppunit":)
• Captura : 11 888 archivos C++ (término de búsqueda: "include catch.hpp"(
• CppUnitLite : 1214 archivos C++ (término de búsqueda "include CppUnitLite":)

(el número en "Hemos encontrado resultados de código xxx" después de hacer clic en C++ en el menú de la izquierda)

Parecería que Google Test es un claro ganador del concurso de popularidad SO+GitHub, probablemente porque fue adoptado por grandes proyectos como LLVM y Chromium.

Me gustaría complementar la respuesta de la wiki de la comunidad con un par de otros puntos a considerar al seleccionar su marco de prueba, esto se refiere a la elección de una herramienta de prueba:

1. Los marcos de prueba gratuitos o de precio razonable, como Google Test y CppUnit, casi siempre estarán a la cabeza en popularidad , pero es posible que no cumplan con sus otros requisitos .
2. Nivel de cobertura de prueba requerido:
   1. Si está probando un código de usuario para un proyecto de software libre simple (aunque muchos de ellos tienen pruebas mucho mejores que los proyectos comerciales) , o un juego, entonces está a la vanguardia si está realizando alguna prueba unitaria.
   2. Si está escribiendo código para una aplicación financiera o un sistema de telecomunicaciones, es probable que requiera, o se le exija, realizar una cobertura del 100 % de las líneas de código, es decir, cada línea de su código debe ejecutarse al menos una vez durante la prueba.
   3. Si está escribiendo una aplicación espacial, militar, médica o de aviación de baja criticidad, deberá realizar una cobertura de línea del 100 % y una cobertura de decisión del 100 %, es decir, cada línea se ejecuta y se ejercen todas las formas de pasar por un punto de decisión.
   4. Si está escribiendo código crítico para la seguridad en cualquiera de las áreas mencionadas anteriormente, se le pedirá que realice el 100 % del código y el 100 % de la cobertura de decisión en el nivel del código de operación, no solo en la cobertura de línea.
3. Cualquier certificación requerida de su herramienta de prueba o cualquier estándar con el que deba probar: no es raro en la industria del software integrado exigir el cumplimiento de MISRA , pero hay otros estándares que se requieren en algunos casos.
4. La cantidad típica de tiempo que lleva producir cada caso de prueba: esto puede diferir enormemente entre las herramientas y tiene un gran impacto en los costos indirectos.
5. Si la herramienta de prueba está disponible para su plataforma de implementación y cadena de herramientas y el tiempo y costo de configurarla.
6. Si la herramienta requiere que modifique su código de alguna manera para ejecutar las pruebas: en algunas de las industrias anteriores, se requiere que las pruebas se realicen en el código fuente no modificado .
7. La idoneidad para la automatización de las pruebas: si planea ejecutar una integración continua o utilizar prácticas extremas/ágiles, entonces poder automatizar sus pruebas e informes de pruebas es una gran ventaja.
8. Longevidad: si su proyecto se ejecuta durante años o su producto recibe soporte durante años, perder su herramienta de prueba es un desastre.
9. La capacidad de controlar la versión de sus scripts de prueba es vital.
10. Lo mismo ocurre con los informes/resultados de las pruebas: también necesita la capacidad de publicar los resultados de las pruebas en un formato al que se pueda acceder sin una copia de la herramienta de prueba.
11. También necesita que sus pruebas y resultados sean rastreables tanto a los requisitos como al código fuente.

Si está realizando pruebas unitarias para software incrustado crítico para la seguridad, existen muy pocas herramientas con las certificaciones y el respaldo de los estándares requeridos. Rational Test RealTime y LDRA Testbed son ejemplos, pero no son baratos , cuestan decenas de miles de dólares por cada licencia por año por desarrollador.

Descargo de responsabilidad : no trabajo para ninguna de las empresas mencionadas anteriormente, pero he usado sus productos ya que he trabajado mucho en la industria crítica de seguridad, integrada y en tiempo real.