Discussion :

[TabrisLeFol]

Bonjour,

Je commence à introduire des tests unitaires dans mon projet et je me trouve confronter a un problème. Comment peut on associer des tests unitaires à une interface et non pas à une classe concrète ?

En effet je souhaite pouvoir tester plusieurs implémentation d'une même interface en utilisant donc les mêmes tests. Existe il une méthode ou un framework qui me permettrait d'éviter un copier-coller qui rendrait difficile la maintenabilité de tels tests ?

D'avance merci

PS : S'il existe plusieurs methodes/frameworks, votre avis est bien sur également le bien venu.

[Kh4iN3]

Salut,

Je connais bien QFTest qui permet de tester les interfaces graphiques, par contre il est payant.

a+

[TabrisLeFol]

Cela n'était peut être pas suffisament explicite dans mon post mais je ne parlais pas d'interface graphique mais d'interface dans le sens Programmation Orienté Objet.

Autrement dit, j'ai un code ressemblant à :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public interface MonInterface {
// methodes
}
 
public classe A implements MonInterface {
// implementation
}
 
public classe B implements MonInterface {
// implementation
}
 
public classe C implements MonInterface {
// implementation
}

Et ainsi de suite, le nombre de sous-classes devant à priori augmenter.

Dans JUnit, le seul moyen serait peut être de passer par une fixture mais je ne sais pas comment.
J'ai par contre trouvé une extension qui devrait à priori permettre ce type de test.
Je ne connais pas d'autres frameworks de test mais cela m'etonne qu'il n'en existe pas un qui permette cela sans extension....

[gifffftane]

Avec JUnit je te conseille d'utiliser des trucs style Netbeans, Eclipse ou Maven ; ils s'occupent de toute la tuyauterie pénible avec JUnit. (particulièrement des fixtures ! )

Pour les interfaces, il n'y a pas de notion de test style JUnit, puisque par définition une interface n'exécute rien, donc pas de tests unitaires. Tu peux faire des tests d'autres formes si tu veux mais, pour les tests unitaires, c'est forcément à partir d'une classe concrète.

[TabrisLeFol]

Oui mais justement. La seule chose que doivent faire les tests est de tester l'implémentation de l'interface. Donc ce sont des tests relatif à l'interface même si bien sur ceux-ci doivent être réalisés sur des classes concretes...

[tnodev]

Bonjour

utilise une classe mère de test contenant

• un attribut de ton interface
• tous les tests des méthodes de l'interface sur l'attribut

puis dans les classes filles de test, tu instancies ton attribut dans le onSetup avec la classe implémentant l'interface et hop...

[gifffftane]

Oui mais justement. La seule chose que doivent faire les tests est de tester l'implémentation de l'interface. Donc ce sont des tests relatif à l'interface même si bien sur ceux-ci doivent être réalisés sur des classes concretes...

Je trouve que tu joues un peu sur les mots. Je pourrais te répondre dans la même veine que ce n'est pas l'implémentation, mais LES implémentations. Etc.

Par construction, en java, on ne sait pas facilement retrouver LES implémentations d'une interface, et on ne peut rien faire avec une interface seule.

À partir de là...

[TabrisLeFol]

@ tnodev : J'y avais pensé mais j'avais de même abandonner l'idée car je pensais que les methodes de tests étaient static. Mais ce n'est pas le cas. Ainsi dès que j'aurais de nouveau accès au projet reuierant de tels tests, j'essayerais.
Par contre cette methode ne permet de centraliser les tests que d'un seul 'contrat' (interface ou classe abstraite) étant donné que l'on passe par un heritage et qu'en Java, ils sont limités à un.

@ gifffftane : Je me suis peut etre mal exprimé mais en tout cas on s'est en effet mal compris. On est d'accord qu'au niveau de l'execution les tests ne peuvent être effectuer que sur des instances (de classes concretes). Cependant ce que je veux tester est l'implementation correcte d'un contrat (interface ou classe abstraite). Et dans ce cas, les tests devront utilisés que les methodes visibles par ce contrat i.e. le type apparant des objets est celui de l'interface/classe abstraite implémentée/héritée. Ainsi meme si les instances appartiennent à des classes (concretes) differentes, les tests (en dehors de l'instanciation) ne devraient pas changer d'une classe à l'autre. D'ou mon désir de pouvoir éviter un copier-coller.

[gifffftane]

Ah mais c'est bien sûr !

Alors moi ce que je fais dans ces cas là :

1. J'observe que, souvent, l'interface dont on veut contrôler les implémentations est associée avec une sorte de classe d'utilitaires ; forcément : ces comportements que l'on veut voir se reproduire à l'identique dans les différentes implémentations doivent bien être écrits quelque part. Par exemple, pour l'interface Serializable, il est écrit dans tous les ObjectInputStream etc.
2. Je case dans cette (ou ces) classes utilitaires les tests concernant les implémentations (par exemple, pour Serializable, il y a un test pour vérifier que l'objet sérialisé est bien de la classe Serializable).
3. Lorsque je fais les tests des classes concrètes, je n'ai plus qu'à appeler les tests présents dans les classes utilitaires.

[TabrisLeFol]

Cette fois-ci, c'est moi qui ne suis pas sur de comprendre.
Tu pourrais me faire des classes/interfaces comme exemple ?

[gifffftane]

Bon. Imaginons une société avec des services divers et variés. Certains sont dotés d'une autonomie (relative) financière, d'autres non.

Il est décidé que le Système d'Information Durable de la Société comporte une classe par service, et que les services qui auront cette autonomie implémenteront l'interface FinancialCapableOptimisable. Interface constitué comme suit (par exemple) :

Code :

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

1
2
 
public BigDecimal getBeneficeMensuel();

Il y aura certaines règles communes ; par exemple, à chaque appel de getBeneficeMensuel, le résultat devra toujours être supérieur au résultat précédent.

Même s'il existe une autonomie financière, même si chaque service sera libre d'implémenter sa comptabilité comme il le veut, il existe des habitudes communes, et le Directeur Du Service d'Information Durable décidera, pour aider, de créer une classe qu'il nommera FinancialCapableOptimisableHelper. Elle comportera par exemple :

Code :

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

1
2
3
4
5
 
public void calculateBeneficeMensuel(FinancialCapableOptimisable serviceCompetitor)
{
 ...
}

Il va de soi qu'il faudra aussi tester la règle : le bénéfice mensuel doit toujours être en hausse. Le Directeur implémentera tout naturellement le contrôle de cette règle dans son helper :

Code :

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

1
2
3
4
5
6
7
8
 
public void checkBeneficeMensuel(FinancialCapableOptimisable serviceCompetitor)
{
 BigDecimal benefice1 = serviceCompetitor.getBenefice();
 BigDecimal benefice2 = serviceCompetitor.getBenefice();
 if (benefice1 >= benefice2)
  throw new IllegalStateException();
}

Admettons maintenant une implémentation concrète de service, par exemple public class CompetitorOptimisatorImperator implements FinancialCapableOptimisable, qui fera ce qu'il voudra, et, lorsque on voudra le tester, il y aura :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public class CompetitorOptimisatorImperatorTestCase extends TestCase
{
 public void testBenefice() throws Exception
 {
  CompetitorOptimisatorImperator competitor;
  FinancialCapableOptimisableHelper helper;
 
  competitor = new CompetitorOptimisatorImperator();
  helper = new FinancialCapableOptimisableHelper();
  helper.checkBeneficeMensuel(competitor);
 }
}

Et voilà. Heu... c'est plus clair ?

[TabrisLeFol]

En effet, merci.