Discussion :

[zaphibel]

Bonjour,
CppUnit lance-t-il des threads en internes et de quel type sur
windows ?
Sinon éclairez moi Merci.

[Luc Hermitte]

Cela me suprendrait.

[zaphibel]

bonjour,
donc tu crois que tout est séquentiel?

[millie]

bonjour,
donc tu crois que tout est séquentiel?

Je pense que la méthode de base est séquentiel, comme avec Junit. Mais qu'il est possible de lancer de manière asynchrone des tests sur les classes (en effet, les lancements de tests sont protégés par des mutex (SynchronizedObject dans cppUnit))

Pourquoi te demandez tu cela ?

On ajoute un teste :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void 
TestRunner::addTest( Test *test )
{
  m_suite->addTest( test ); 
}

On lance la batterie de test :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
void 
TestRunner::run( TestResult &controller,
                 const std::string &testPath )
{
  TestPath path = m_suite->resolveTestPath( testPath );
  Test *testToRun = path.getChildTest();
 
  controller.runTest( testToRun );
}

Le controlleur ne faisait qu'exécuter runTest du Test:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
void 
TestResult::runTest( Test *test )
{
  startTestRun( test );
  test->run( this );
  endTestRun( test );
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
void 
TestCase::run( TestResult *result )
{
  result->startTest(this);
 
...    result->protect( TestCaseMethodFunctor( this, &TestCase::runTest ),
                     this );

Enfin, le TestResult fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
void 
TestResult::startTest( Test *test )
{ 
  ExclusiveZone zone( m_syncObject ); 
  for ( TestListeners::iterator it = m_listeners.begin();
        it != m_listeners.end(); 
        ++it )
    (*it)->startTest( test );
}

A ce moment, on voit apparaître un mutex qui laisse présager la possibilité de lancer des tests dans plusieurs threads.

Après, j'avoue m'être à moitié paumé dans le code et j'ai eu la flemme de réflechir d'avantage

[zaphibel]

Bonsoir,
Tout d'abord Merci pour l'attention que tu as apporté à ma question.
Ce code me permet d'éclaircir un gros problème lié à mes tests.
Car j'utilise ACE (adaptive communication enviroment) et j'utillise
des Mutex. Il se trouve que seul mon application qui utilse les
mutex tourne parfaitement. Mais en l'integrant à des tests avec
cppUnit il se trouve que mes Tasks (pour être précis employés
par ACE) ne se lancent plus car ils n'ont jamais la main.
Ce qu iaboutit à un crash sur un Mutex d'ACE de temps en temps.
Il semblerait qu'il y ait un conflit de Mutex; L'emploi de plusieurs
frameworks pourrait ne pas être compatible à ce que je vois.
Naturellement ce n'est qu'une théorie pour l'instant qui demande
à être vérifiée.
Merci Arigato ^^

[Luc Hermitte]

Cela me parraitrait complètement idiot comme approche. Quid des nombreux codes non réentrants, ou des machines mono-proc. Il n'y a pas d'option pour empêcher cela ?

Sinon, tu peux toujours te diriger vers des frameworks de TU plus complets, plus simples, et mieux foutus (cxxtest p.ex.)

[millie]

Sinon, tu peux toujours te diriger vers des frameworks de TU plus complets, plus simples, et mieux foutus (cxxtest p.ex.)

EDIT : Désolé, j'avais lu cxxUnit, mais pas cxxTest. Cela dit, je vais laisser le message qui montre les limites de cxxUnit.


J'avais utilisé cxxUnit dans un projet pour faire des tests unitaires, mais j'ai trouvé que cet outil avait des limites très importantes. Notamment lorsque l'on essayé de faire une architecture de test particulier (qui testent par exemple plusieurs implémentation d'une interface). Typiquement, dans un cas comme ça :

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
/*interface*/
class Interface {
 public: 
  virtual void methode() = 0;
  virtual ~Interface() {}
};
 
class Implementation1 : public Interface ...
class Implementation2 : public Interface ...

Les tests unitaires peuvent tester l'interface et s'écrivent sous la forme :

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
class TestInterface : public cxxUnit {
 public:
  virtual Interface * getInstance() = 0;
  void testMonPremierTest() { ....}
 
};

Classiquement, pour tester chaque implémentation, on faisait :

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
class TestImplementation1 : public TestInterface {
 public:
  Interface * getInstance() {
   return new Implementation1();
  }
};

Mais cxxUnit n'arrive pas du tout à gérer ces architectures En plus, il est nécessaire de disposer de Perl pour pouvoir précompiler les fichiers de tests (convertit un fichier de test en un fichier cpp).

[Luc Hermitte]

CxxTest utilise bien perl. Et j'ai peur que le parser ne reconnaisse pas ce qu'il attend dans ce cas. Il faudrait que j'essaie pour voir.

En jouant sur les makefile (pour linker avec un .o ou un autre, qui fourniront deux Interface* différents) il est possible de régler cela toutes fois.

[zaphibel]

Bonjour,
Il se trouve que les tests ont tous été fait avec cppUnit et je devais integrer
mon travail dans leur suite de tests. En plus c'est très particulier puisque je le fais sur Windows. ACE signale quelques remarque concernant leur mutex sous windows. Et donc il y a forcément une autre définition de l'emploi des Mutex POSIX qui pourrait ne pas poser de problème. Du coup on compte peut être juste appelé mon appli de l'extérieur vérifier son résultat et pas l'intégrer dans la suite de tests.