Cadre de test CXX pour C++

Question

Quelle est l'efficacité de la structure de test CXX, étant donné que vous écrivez des cas de test unitaires autour du code que vous avez écrit. Un bogue dans le code pourrait également se traduire par un bug dans le code de test unitaire? N'est-ce pas quelque chose comme deux négatifs font un positif?

En outre, le temps et les efforts consacrés à CXX sont au moins égaux sinon supérieurs à l'effort de codage.

Besoin de votre avis à ce sujet puisque je ne suis pas en faveur de ce cadre étant utilisé dans mon projet et je cherche des points forts pour s'y opposer. En revanche, si vous pensez que c'est bénéfique, s'il vous plaît éclairer moi :).

Answer 1

CXX n'est pas très actif, et le test d'unité d'écriture implique généralement beaucoup d'efforts. Mais quand le premier refactoring arrive, vous êtes très reconnaissant de l'effort dépensé. J'ai utilisé Boost.Test & CPPUNIT. Je préférerais un peu Boost.Test, mais oui, vous devez écrire vos propres projets, fichiers, etc.

Si vous connaissez un outil pour générer votre squelette à partir de votre code, je suis tout ouïe. :)

Je vous suggère d'essayer Boost.Test et CPPUNIT. Si vous pensez qu'il y a mieux, cela vous donnera de bonnes chances de vous opposer à CXXUNIT car vous proposerez des alternatives.

Answer 2

J'utilise cxxtest. Les tests régressifs sont une tâche coûteuse que nous utilisons uniquement pour valider nos bibliothèques logicielles, qui fournissent une couche indépendante de la plate-forme pour nos applications. C'est pour s'assurer que tous les changements n'affecteront pas la stabilité du code depuis tant d'applications et de projets et en dépendent.

Nous couplons cxxtest avec une analyse de couverture pour garantir que la couverture de test est suffisante et également avec CruiseControl pour l'automatiser.

Mais nous ne faisons pas cela pour les applications. Trop d'effort.

La création d'une application de test est tout aussi difficile que l'écriture de toute la bibliothèque elle-même. Je suis d'accord que vous aurez besoin de savoir si cela vaut la peine.

Je pense que Joel a quelque chose à dire à ce sujet aussi: http://www.joelonsoftware.com/items/2009/01/31.html

Answer 3

Google propose un framework de test C++ fantastique que je l'ai utilisé ... Je jamais utilisé tout autre framework de test C++, et avait limité expérience avec Junit, et j'ai été en mesure de ramasser très rapidement rapidement, car la documentation est bonne. Il est important d'utiliser un bon cadre de test, car les tests sont trop importants pour être abandonnés en raison de la frustration liée au cadre. Voici un lien:

http://code.google.com/p/googletest/

Hope this helps!

Answer 4

Je préfère les frameworks de test en-tête seulement, voici deux d'entre eux: TUT et Catch. J'ai utilisé TUT auparavant dans plusieurs projets, et j'ai trouvé Catch il n'y a pas longtemps.

1) TUT - C++ Framework Modèle Test Unit

TUT est un petit cadre portable de test unitaire pour C++.

• TUT est très portable, peu importe quel compilateur ou OS que vous utilisez.
• TUT est constitué uniquement de fichiers d'en-tête. Aucune bibliothèque requise, le déploiement n'a jamais été aussi facile.
• L'interface reporter personnalisée permet d'intégrer TUT avec pratiquement n'importe quel IDE ou outil dans le monde.
• Prise en charge des tests multiprocessus (le test des blocages et des délais d'attente est en cours).
• TUT est gratuit et distribué sous licence BSD.
• Les tests sont organisés en groupes de tests nommés.
• Régression (tous les tests dans l'application), exécution d'un seul groupe ou d'un test.
• Pure C++, pas de macros!

2) Catch - Un moderne, C++ - natif, en-tête uniquement, cadre de tests unitaires, TDD et BDD

Quel est le piège? Catch est synonyme de cas de test automatisés C++ dans les en-têtes et est un cadre de test automatisé multi-paradigme pour C++ et Objective-C (et, peut-être, C). Il est implémenté entièrement dans un ensemble de fichiers d'en-tête, mais est emballé comme un en-tête unique pour plus de commodité.