Récupération d'exceptions à l'aide de CPPUnit

Question

J'utilise CPPUnit comme infrastructure de test unitaire et j'essaie maintenant de l'utiliser dans un système de génération et de package automatisé. Cependant, un problème qui me retient est que si un crash se produit pendant l'exécution des tests unitaires, par ex. un pointeur nul déréférencé, il arrête le reste de l'automatisation.

Existe-t-il un moyen permettant à CPPUnit de récupérer cette exception, d’enregistrer l’échec du test, puis d’exister correctement plutôt que de mettre fin au processus de test unitaire? Même une approche spécifique de la déréférencement de pointeurs nuls serait utile car elle représente environ 90% des problèmes que j'ai rencontrés.

Pour être spécifique à la technologie, j'utilise des makefiles sur un système Windows.

Answer 1

Vous automatisez l'exécution de vos tests unitaires basés sur cppunit lors de votre processus de construction, n'est-ce pas?

Si vous essayez d'utiliser CppUnit pour exécuter le processus de construction, je serais tenté de dire que vous ne le ferez pas!

Pouvez-vous nous dire ce qui bloque le processus de construction lorsque les tests unitaires se bloquent? Et quels sont vos tests unitaires commencés par un Makefile, un script de votre choix ou un intégration continue cadre ?

Pour tenter de répondre à votre question, CppUnit ne peut pas récupérer d’erreurs de violation ou de segmentation. Sur les systèmes de type Unix, vous devriez pouvoir capturer le SIGSEGV et continuer, mais dans quel état ?

Si vos accidents se produisent dans votre test unitaire et non dans votre produit, je vous recommanderais de vous fier à gardes d'assertion pour empêcher le déréférencement des pointeurs NULL:

class TestObject : public CPPUNIT_NS::TestCase
{
  CPPUNIT_TEST_SUITE(Test);
  CPPUNIT_TEST(testObjectIsReady);
  CPPUNIT_TEST_SUITE_END();

public:
  void setUp(void) {}
  void tearDown(void) {} 

protected:
  void testObjectIsReady(void)
  { 
     Object *theObject = GetObject();

     CPPUNIT_ASSERT_MESSAGE("check pointer is not null", theObject != NULL);

     //--- now you can play with your object without dereferencing a NULL pointer
     CPPUNIT_ASSERT_MESSAGE("check objet is ready", theObject->isReady());
  }
};

Answer 2

Désolé de le dire, mais les réponses précédentes que vous avez reçues sont ridicules. Cppunit manque vraiment à cet égard. cppunit doit implémenter une macro EXIT_ON_FAIL qui vous permet d'intercepter la violation d'accès dans Windows (à l'aide de SetUnhandledExceptionFilter), puis vous pouvez effectuer n'importe quel nettoyage et autoriser cpp-unit à signaler l'échec via EXIT_ON_FAIL. Ensuite, après avoir signalé, quittez l'application.

Answer 3

En C / C ++, le meilleur moyen de remédier à de telles erreurs consiste à exécuter chaque test dans un processus distinct, puis à les surveiller à partir d'un processus parent. C’est très facile sous UNIX - il suffit d’indiquer fork () avant le début du test. check prend en charge cette option, et vous pourriez probablement corriger le comportement de CPPUnit pour éviter ce problème.

Answer 4

Comme remarque supplémentaire pour ceux qui ont lu cette question ultérieurement, j'ai trouvé UnitTest ++ peut détecter les exceptions dans les tests et échouer simplement avec des informations appropriées au lieu d’aboutir à une sortie du processus.

Answer 5

Je ne l'ai pas essayé, mais si sous Windows, utiliser SEH aiderait:

__try
{
// running your case
}

__except
{
}

Intégrez-le dans la structure CppUnit, et chaque fois que vous recevez une exception inconnue, marquez le cas comme un échec.