Quel cadre de test unitaire pour les jeux basés sur c ++? [fermé]

Selon vous, quelle combinaison d'outils de test est la meilleure? Compte tenu du cadre / bibliothèque de votre choix, vous pourriez envisager:

• adéquation pour TDD
• facilité d'utilisation / productivité
• traiter des objets fictifs
• configuration avec intégration continue
• rapport d'erreurs

Remarque: Bien que ce soit potentiellement une question générique comme celle sur SO, je dirais que le développement de jeux est généralement lié à un flux de travail spécifique qui influence le choix pour les tests. Pour une perspective de niveau supérieur, voir la question Test automatisé des jeux .

J'ai trouvé UnitTest ++ très facile à utiliser. Je devrai encore essayer amop avec lui, qui a été mentionné comme un bon compagnon pour UnitTest ++ pour la fonctionnalité des objets fictifs. Sinon, Google Mock est un choix populaire. En outre, vous souhaiterez peut-être lire sur UnitTest ++ et Mock Objects .

UnitTest ++ peut être configuré avec votre approche d'intégration continue, par exemple avec Hudson

Vous voudrez peut-être lire cet article inspirant si vous n'êtes pas convaincu que les tests unitaires et les jeux vont bien ensemble.

Un autre vote pour UnitTest ++ . Très facile à intégrer, compilé pour notre plate-forme embarquée cible très facilement, simple et facile à utiliser. Nous l'avons également intégré à Hudson. Nous avons examiné GoogleTest, mais nous l'avons rejeté (je pense qu'il a eu des problèmes de compilation pour notre plate-forme cible), mais il dispose d'un ensemble de fonctionnalités similaires et pourrait vous convenir.

De plus, vous voudrez peut-être examiner une sorte de cadre de test de fumée. D'après mon expérience, il est difficile d'obtenir une couverture de test suffisante pour un jeu avec des tests unitaires seuls. Surtout si vous introduisez des tests unitaires dans une base de code existante, et même plus pour une grande équipe. Le test de fumée serait de tester des choses de haut niveau comme "assurez-vous que tous les niveaux se chargent". Ma théorie est que si j'ai les deux types de tests, à un moment donné, ils pourraient se rencontrer au milieu et donner un effet de levier décent. :)

À l'époque où je travaillais en C ++ (avertissement: c'était vers 2005), j'ai utilisé une version légèrement modifiée de TUT (Template Unit Test Framework) . Je l'ai aimé parce qu'il était si léger, ce qui le rendait facile à modifier et signifiait qu'il y avait très peu de «colle» requise lors de l'écriture des tests.

Voici une modification très simple que j'ai apportée, qui rend encore plus facile / plus simple d'écrire des tests:

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__)

L'autre modification que j'ai apportée concerne son format de sortie, de sorte que les échecs de test apparaissent correctement dans la liste d'erreurs de Visual Studios (lorsqu'ils sont exécutés dans le cadre d'une build), cliquable pour accéder au fichier et à la ligne du test ayant échoué.

(La possibilité de faire ce genre de chose signifie qu'elle peut être faite pour s'intégrer dans votre processus TDD / CI, plutôt que de vous forcer à vous y intégrer.)

Voici un exemple de test (de la pile de commandes de mon éditeur):

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);
}

(Dans le code ci-dessus, cset odsont des luminaires par module, et TestCommandest un objet factice.)

En ce qui concerne le C ++, j'ai essayé et utilisé le framework googletest, http://code.google.com/p/googletest/ . Il est simple à configurer, facile à utiliser et fonctionne très bien.

Je ne suis pas un développeur de jeux professionnel, mais je suis un développeur professionnel intégré. Peut-être pas exactement comme des jeux mais proche. Sur mon lieu de travail, nous en avons utilisé quelques-uns.

J'aime vraiment google test . Il possède toutes les meilleures fonctionnalités des frameworks de tests unitaires récents, tout en conservant le tout dans une interface minimale et rationalisée.

Le prochain sur ma liste est Boost Test . L'API de Google test est un peu plus moderne que Boost.Test, mais Boost Test a fait un travail incroyable en ajoutant de nouvelles fonctionnalités et en abandonnant le paradigme croustillant CppUnit.

J'ai également utilisé CxxTest . C'est assez bien fait, mais vous pouvez dire que ce n'est pas aussi moderne que Boost.Test ou Google Test. En particulier, son support pour les suites de tests et les appareils est un peu gênant.

J'aime utiliser les fonctionnalités avancées, mais si vous êtes minimaliste, vous ne verrez jamais la différence entre les trois. La plupart de mes collègues seraient satisfaits d'un cadre de test unitaire qui prend en charge le test d'enregistrement automatique (de manière déclarative) et possède une sorte de macro CHECK_EQUALS (a, b).

Ma bibliothèque de tests préférée est QuickCheck http://en.wikipedia.org/wiki/QuickCheck . Il existe une version C ++ expérimentale, mais elle semble trop lourde, mais même sans bibliothèque dédiée, les principes sont faciles à utiliser.

Toutes mes classes ont une méthode genArbitrary qui peut générer une instance aléatoire. Je l'utilise pour tester la fumée des processus inversibles, comme le chargement et le déchargement. Je peux générer des milliers de scènes aléatoires et vérifier que diverses propriétés se tiennent (comme la scène que je sérialise est la même que la scène que je désérialise).

Il ne remplace pas les tests unitaires traditionnels (il réduit le besoin de nombreux tests unitaires potentiels), mais c'est un excellent moyen de découvrir les bogues, et il aide à tester la résistance de ma stratégie d'allocation de mémoire (avec Valgrind). C'est génial de voir plus d'un million d'allocations sortir Valgrind pur :).

J'ai utilisé CxxTest comme harnais de test, ce que j'ai aimé. Maintenant, tous mes tests sont des ex séparés. J'ai juste un dossier appelé Test, et chaque fichier qui commence par Test_ devient un test. Jusqu'à présent, c'est un poids léger très facile à réaliser.

Avec Java, il y a tellement de bonnes bibliothèques ... Pas le cas de C ++.

Pour les utilisateurs C ++, il existe un outil de chaîne de Kitware qui est très intéressant:

• CMake: faire un outil
• CDash: outil d'intégration continue

Kitware écrit des codes C ++ pour l'informatique.

Pour les projets personnels, j'utilise la bibliothèque de tests unitaires Boost (sur la plateforme Desktop). Pour l'intégration continue, j'utilise Hudson:

• installation facile sur Tomcat
• scriptable

J'appuie le framework TUT (Template Unit Test) ; il est super léger et extrêmement flexible, sans oublier qu'il est très facile à configurer et à utiliser dès la sortie de l'emballage (un seul en-tête comprend, un peu de code principal / de configuration et 24 lignes de code de test plus tard, vous avez un test unitaire). Je l'ai combiné avec binfmtc (exécutez des programmes C ++ en tant que scripts) pour un prototypage rapide / TDD / modèles d'apprentissage avec beaucoup de succès, y compris le développement de logiciels intégrés. En raison de sa capacité de sortie en XML, il s'intègre également parfaitement avec Jenkins (CI) et Sonar sur mes projets successifs.