Equivalent des protections CppUnit pour boost :: test?

Question

J'ai utilisé à la fois CppUnit et boost::test pour C++ unittesting. En général, je préfère boost::test, principalement parce que les macros d'auto-test minimisent les efforts pour configurer les tests. Mais il y a une chose qui me manque vraiment chez CppUnit: la possibilité d'enregistrer vos propres "protecteurs", dont les instances enveloppent automatiquement tous les tests d'exécution. (Techniquement, vous installez un test "écouteur", et qui peut envelopper chaque test dans une portée protector).

J'ai trouvé ces informations précieuses dans le passé pour surveiller les tests unitaires d'effets secondaires inattendus (par exemple, le contrôle du code n'a pas modifié les indicateurs d'état des unités à virgule flottante). Je ne peux pas voir d'équivalent dans le boost::testdocumentation, bien que BOOST_FIXTURE_TEST_CASE se rapproche peut-être le plus proche.

Des suggestions sur la meilleure façon de réaliser la même chose que les protections CppUnit dans boost::test?

(Je n'ai pas encore vraiment examiné l'implémentation de boost::test, mais si c'est quelque chose comme CppUnit il doit utiliser quelque chose comme des protecteurs lui-même).

Answer 1

Je n'ai jamais utilisé CppUnit, donc je ne sais pas comment fonctionnent les protecteurs. Cherchez-vous quelque chose qui enveloppe des tests individuels, ou toute la suite de tests? Pour le premier, vous pouvez utiliser des appareils comme vous le mentionnez, mais si je comprends bien, les appareils doivent être considérés comme «en dehors» du test. Ils mettent en place tout ce dont le test a besoin et le nettoient ensuite. Tout test d'erreur réel devrait être dans le test lui-même, mais peut être facilement mis en œuvre avec RAII. Définissez simplement une classe qui vérifie tout ce dont vous avez besoin dans son destructeur, puis créez une instance locale au début du test. Comme il est construit en premier, il est détruit en dernier, donc il peut facilement vérifier que le test n'a modifié aucun état inattendu.

Si vous voulez vérifier cela après tous les tests ont exécuté, vous voulez probablement global fixtures