tipos - Bibliotecas de pruebas unitarias de C++

pruebas unitarias interfaz

Question

Me encontré con cppunit, pero no se veía súper fácil de usar (tal vez no parecía difícil, tal vez porque C ++ no funciona como Java / C #). ¿Hay alternativas simples ampliamente utilizadas?

De hecho, ¿ es cppunit el marco de prueba de unidad estándar para C ++?

Answer 1

Aquí hay una lista de bibliotecas de pruebas unitarias.

http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B

Sin embargo, hasta donde yo sé, cppunit es el más popular.

Answer 2

gtest , el marco de prueba de Google es una alternativa.

Aquí hay un ejemplo simple de la documentación :

// Tests factorial of 0.
TEST(FactorialTest, HandlesZeroInput) {
EXPECT_EQ(1, Factorial(0));
}
// Tests factorial of positive numbers.
TEST(FactorialTest, HandlesPositiveInput) {
EXPECT_EQ(1, Factorial(1));
EXPECT_EQ(2, Factorial(2));
EXPECT_EQ(6, Factorial(3));
EXPECT_EQ(40320, Factorial(8));
}

También funciona muy bien con gmock , el marco simulado de Google para C ++

Answer 3

CppUnit probablemente sea el primer marco de prueba de unidad para C ++. Es un puerto directo de Junit, el famoso framework de Java. Esto facilita la transición de Junit, pero a costa de un marco algo pesado, que no aprovecha la capacidad de C ++ como RAII. Esa es la razón por la cual se han creado versiones ligeras como CppUnitLite, NanoCppUnit. Se suponía que CppUnit2 mejoraría esto, entre otras mejoras.

Tut solía ser muy ligero, solo un encabezado, pero las últimas versiones introdujeron una biblioteca.

En lo que respecta a un marco "estándar", no existe ninguno, y C ++ 1X no define uno.

Answer 4

Creé un conjunto de pruebas llamado saru ( http://github.com/squishyhumans/saru ) para mi propio desarrollador de código. Es un código con licencia de BSD. Lo desarrollé porque no me gustaron muchas de las características de otras suites de prueba. No se usa ampliamente, pero lo he usado en varios proyectos comerciales repartidos en dos compañías.

1. No me gusta que todas mis pruebas se compilen en un binario. Mis razones para esto son si la compilación falla todas las pruebas fallan, si una prueba tiene un comportamiento indefinido, la salida del programa no está definida.
2. Quiero control sobre qué pruebas se ejecutan. Quiero poder agrupar las pruebas y ejecutar subconjuntos.
3. Deseo que la falla en la compilación de una prueba se notifique como una falla de prueba, y no suspender todas las pruebas que se ejecutan.
4. Quiero poder realizar pruebas desde varios idiomas diferentes
5. Quiero un sistema lo suficientemente flexible como para poder ejecutar pruebas específicas bajo valgrind (aún no en saru :()

Así que saru aborda la mayoría de estas características. Su foco está en poder ejecutar un conjunto de pruebas escritas en diferentes idiomas. Con tamaños de prueba mínimos. Aquí está la prueba de C ++ más pequeña (fallida)

//SARU : dummy dummy
int main() { return (1==2)?0:1; }

Lo único que realmente le importa a Saru es el valor de retorno del binario que compila. Luego analiza la salida para determinar qué pruebas fallaron y así sucesivamente. Tiene encabezados para hacer que trabajar con C ++ sea un poco mejor que el ejemplo trivial anterior:

//SARU : dummy dummy
#include "MyStruct.h"
#include "saru_cxx.h"
class Fixture
{
MyStruct s_;
Fixture() : s_() {}
void test_A_is_B()
{
SARU_ASSERT_EQUAL( s_.A(), s_.B() );
}
void test_C_is_7()
{
SARU_ASSERT_EQUAL( 7, s_.C() );
}
};
int main()
{
saru::TestLogger logger;
SARU_TEST( Fixture:: test_A_is_B, logger );
SARU_TEST( Fixture:: test_C_is_7, logger );
logger.printSummary();
return logger.allOK()?0:1;
}

O si no le gusta la forma en que funcionan sus encabezados C ++, debería ser capaz de integrarse con otras bibliotecas de pruebas unitarias con una dificultad mínima.

Pero también ejecutará pruebas escritas en PHP y Python. Entonces puede configurar pruebas funcionales completas con saru. O puede ejecutar algo como pelusa sobre su código como parte del conjunto de pruebas.

Answer 5

No hay una biblioteca de prueba de unidad estándar para C ++. Hay muchas opciones para elegir; cppunit es uno de ellos.

En mi empresa utilizamos Google Test junto con su socio Google Mock para pruebas de unidades y burlas de objetos. Los encuentro combinados más fáciles de usar y mucho más poderosos que cppunit.

Answer 6

Acabo de sacar mi propio marco, CATCH , por ahí. Todavía está en desarrollo, pero creo que ya supera a la mayoría de los otros marcos. Diferentes personas tienen diferentes criterios, pero he tratado de cubrir la mayor parte del terreno sin demasiadas concesiones. Eche un vistazo a mi entrada de blog vinculada para una prueba. Mis cinco principales características son:

• Solo encabezado
• Registro automático de funciones y pruebas basadas en métodos
• Descompone las expresiones estándares de C ++ en LHS y RHS (por lo que no necesita una familia completa de macros assert).
• Soporte para secciones anidadas dentro de un accesorio basado en función
• Pruebas de nombres usando lenguaje natural - se generan nombres de funciones / métodos

También tiene enlaces de Objective-C.

A modo de ejemplo, así es como escribirías el equivalente del ejemplo de gtest que @dmeister citó:

TEST_CASE( "Factorial/Handles zero input", "Tests factorial of 0.")
{
REQUIRE( Factorial(0) == 1 );
}
TEST_CASE( "Factorial/Handles positive input", "Tests factorial of positive numbers.")
{
REQUIRE( Factorial(1) == 1 );
REQUIRE( Factorial(2) == 2 );
REQUIRE( Factorial(3) == 6 );
REQUIRE( Factorial(8) == 40320 );
}

Si una prueba falla, aún obtendría los valores de LHS y RHS registrados independientemente.

Answer 7

Aquí hay una biblioteca mínima de pruebas de unidades de C ++: https://github.com/vahidk/minimal-cpp-test

Tiene una sintaxis muy similar a la biblioteca de pruebas de Google, pero es solo una biblioteca de encabezado y, por lo tanto, es más fácil de transportar a través de las plataformas.

Aquí hay una prueba unitaria mínima:

#define DEFINE_TEST_MAIN
#include "test.h"
TEST(GroupName, TestName) {
EXPECT_EQ(1 + 2, 3);
}

Y un accesorio mínimo:

class ClassName : public cyrus:Test {
public:
void Setup() override {
x = 5;
}
int x;
}
Test_F(ClassName, Test1) {
EXPECT_EQ(x, 5);
}

Espero que esto ayude.