¿Qué marco de prueba de unidad para juegos basados ​​en c ++? [cerrado]

¿Qué combinación de herramientas de prueba crees que es mejor? Dado el marco / biblioteca de su elección, puede considerar:

• idoneidad para TDD
• facilidad de uso / productividad
• tratar con objetos simulados
• configuración con integración continua
• error al reportar

Nota: Si bien esta es una pregunta potencialmente genérica como la de SO , diría que el desarrollo del juego generalmente está vinculado a un flujo de trabajo específico que influye en la elección de las pruebas. Para una perspectiva de nivel superior, vea la pregunta Prueba automatizada de juegos .

Encontré que UnitTest ++ es muy fácil de trabajar. Sin embargo, voy a tener que tratar Amop junto con él, que fue mencionado para ser un buen compañero de unittest ++ para las funciones objeto de burla. De lo contrario, Google Mock es una opción popular. Además, es posible que desee leer sobre UnitTest ++ y Mock Objects .

UnitTest ++ se puede configurar con su enfoque de integración continua, por ejemplo, con Hudson

Es posible que desee leer esta publicación inspiradora si no está convencido de que las pruebas unitarias y los juegos van bien juntos.

Otro voto para UnitTest ++ . Muy fácil de integrar, compilado para nuestra plataforma embebida de destino de manera muy sencilla, directa y fácil de usar. También lo hemos integrado con Hudson. Analizamos GoogleTest pero lo rechazamos (creo que tenía problemas para compilar para nuestra plataforma de destino), pero tiene un conjunto de características similares y podría ser adecuado para usted.

Además, es posible que desee examinar algún tipo de marco de prueba de humo. En mi experiencia, es difícil obtener suficiente cobertura de prueba para un juego solo con pruebas unitarias. Especialmente si está introduciendo pruebas unitarias a una base de código existente, e incluso más para un equipo grande. La prueba de humo sería probar cosas de alto nivel como "asegúrese de que todos los niveles se carguen". Mi teoría es que si tengo ambos tipos de pruebas, en algún momento podrían encontrarse en el medio y dar una cobertura decente. :)

Cuando trabajaba en C ++ (descargo de responsabilidad: esto fue alrededor de 2005), usé una versión ligeramente modificada de TUT (Template Unit Test Framework) . Me gustó porque era muy liviano, lo que facilitaba la modificación y significaba que se requería muy poco "pegamento" al escribir pruebas.

Aquí hay una modificación muy simple que hice, que hace que sea aún más fácil / limpio escribir pruebas:

static int BogusFunction() { return __COUNTER__; } // Increment the __COUNTER__ to the correct position for the begining of the tests
#define TEST template<> template<> void object::test<__COUNTER__>()
#define ENSURE(msg, cond) ensure(msg, cond, __FILE__, __LINE__)
#define ENSURE_EQUALS(msg, actual, expected) ensure_equals(msg, actual, expected, __FILE__, __LINE__)
#define ENSURE_DISTANCE(msg, actual, expected, distance) ensure_distance(msg, actual, expected, distance, __FILE__, __LINE__)
#define FAIL(msg) fail(msg, __FILE__, __LINE__)

El otro cambio que hice fue a su formato de salida, para que las fallas de prueba aparecieran correctamente en la lista de errores de Visual Studios (cuando se ejecuta como parte de una compilación), haga clic para ir al archivo y la línea de la prueba fallida.

(La capacidad de hacer este tipo de cosas significa que se puede hacer que se ajuste a su proceso TDD / CI, en lugar de obligarlo a adaptarse a él).

Aquí hay un ejemplo de prueba (de la pila de comandos de mi editor):

TEST // Undoing a command
{
    cs.AddCommand(new TestCommand);
    cs.AddCommand(new TestCommand(od));

    ENSURE("Undo success", cs.Undo());
    ENSURE_EQUALS("Stack size", cs.size(), 2);
    ENSURE_EQUALS("Command's Undo() was called", od.undo, 1);
    ENSURE_EQUALS("Command's Redo() not called", od.redo, 0);

    ACommandStack::const_iterator it = cs.end();
    ENSURE("Command is redoable", cs.GetUndoPos() == --it);
}

(En el código anterior, csy odson accesorios por módulo, y TestCommandes un objeto simulado).

Cuando se trata de C ++, probé y utilicé el marco de googletest, http://code.google.com/p/googletest/ . Es simple de configurar, fácil de usar y funciona muy bien.

No soy un desarrollador profesional de juegos, pero sí soy un desarrollador profesional integrado. Quizás no exactamente como juegos, pero cerca. En mi lugar de trabajo hemos usado algunos.

Realmente me gusta la prueba de google . Tiene todas las mejores características de los marcos de prueba de unidad recientes, mientras lo mantiene todo en una interfaz mínima y optimizada.

El siguiente en mi lista es Boost Test . La API de Google Test es un poco más moderna que Boost.Test, pero Boost Test ha hecho un trabajo increíble al agregar nuevas funciones y deshacerse del paradigma de CppUnit.

También he usado CxxTest . Está bastante bien hecho, pero se nota que no es tan moderno como Boost.Test o Google Test. En particular, su soporte para conjuntos de pruebas y accesorios es un poco incómodo.

Me gusta usar las funciones avanzadas, pero si eres minimalista, nunca verás la diferencia entre las tres. La mayoría de mis colegas estarían contentos con un marco de prueba de unidad que admite la prueba de registro automático (de manera declarativa) y tiene algún tipo de macro CHECK_EQUALS (a, b).

Mi biblioteca de pruebas favorita es QuickCheck http://en.wikipedia.org/wiki/QuickCheck . Existe una versión experimental de C ++, pero parece demasiado pesada, pero incluso sin una biblioteca dedicada, los principios son fáciles de usar.

Todas mis clases tienen un método genArbitrary que puede generar una instancia aleatoria. Utilizo esto para probar el humo de procesos invertibles, como la carga y descarga. Puedo generar miles de escenas aleatorias y verificar que se mantengan varias propiedades (como la escena que serializo es la misma que deserializo).

No reemplaza las pruebas unitarias tradicionales (reduce la necesidad de muchas pruebas unitarias potenciales), pero es una excelente manera de descubrir errores, y ayuda a probar mi estrategia de asignación de memoria (junto con Valgrind). Es genial ver salir más de un millón de asignaciones Valgrind pure :).

Solía ​​usar CxxTest como un arnés de prueba, lo que me gustó. Ahora todas mis pruebas son exes separados. Solo tengo una carpeta llamada Test, y cada archivo que comienza con Test_ se convierte en una prueba. Hasta ahora, es un peso ligero realmente fácil de realizar.

Con Java, hay tantas buenas bibliotecas ... No es el caso de C ++.

Para los usuarios de C ++, hay una herramienta de cadena de Kitware que es muy interesante:

• CMake: hacer herramienta
• CDash: herramienta de integración continua

Kitware escribe códigos C ++ para informática.

Para proyectos personales, uso la biblioteca de prueba de la unidad Boost (en la plataforma de escritorio). Para la integración continua, uso Hudson:

• instalación fácil en Tomcat
• programable

Voy a segundo el TUT (Plantilla de prueba de unidad) Marco ; es súper liviano y extremadamente flexible, sin mencionar que es realmente fácil de configurar y usar de fábrica (un solo encabezado incluye, un poco de código principal / de configuración y 24 líneas de código de prueba después de que tenga una prueba de unidad). Lo he combinado con binfmtc (ejecuta programas de C ++ como scripts) para crear prototipos rápidos / TDD / plantillas de aprendizaje con gran éxito, incluido el desarrollo de software integrado. Debido a su capacidad de salida a XML, también encajó perfectamente con Jenkins (CI) y Sonar en proyectos míos sucesivos.