Test Unitaire

Java -  
KX Messages postés 16761 Date d'inscription   Statut Modérateur Dernière intervention   -
Bonjour,

Actuellement j'utilise JUNIT pour faire passer des tests sur les classes que je créer et cela fonctionne mais je voulais savoir s'il m'était possible de générer des tests unitaires automatique et déjà rempli pour m'éviter de taper tout à là main car je dois rester un classe (que j'ai écrit) qui possède au moins 30 tests !

Sauriez-vous si cela existe sur éclipse s'il vous plaît ?

Merci d'avance pour votre aide.
A voir également:

1 réponse

Réponse 1 / 1
KX Messages postés 16761 Date d'inscription   Statut Modérateur Dernière intervention   3 020
 
Bonjour,

Quels genres de tests voudrais-tu automatiser ?

Parfois avec de la réflexion, 
Class.getMethod()
&co, on peut faire un test générique et le paramétrer avec 
@RunWith(Parameterized.class)
mais c'est du cas par cas et on ne sait pas trop quel est ton contexte précis.

Mais en soit 30 tests ce n'est pas énorme non plus, des tests bien fait nécessitent du temps de développement, parfois même plus que le code qui est testé...
0
Java
 
En fait, il s'agit simplement d'affirmer si quelque chose est vrai ou faux avec assert (par exemple)ou même de vérifier si une pile est vide ou rempli par exemple.

Et je me suis trompé en écrivant, il s'agit de 300 test à faire passer

Merci
0
KX Messages postés 16761 Date d'inscription   Statut Modérateur Dernière intervention   3 020 > Java
 
Aussi simple soit le test au final, la difficulté va venir de comment traiter le code source pour en déduire quel type de test il faut mettre en face. Cela peut se faire sur quelques scénarios bien précis (par exemple la cohérence entre un setteur et son getteur) mais comme je le disais c'est du cas par cas.

Des outils il y en a, par exemple junit-tools ou randoop mais ce ne sera pas magique, sauf pour quelques situations identifiables il faudra quand même coder les tests un à un.

Remarque : écrire des tests à partir du code c'est déjà supposer que le code est correct, ce qui va conduire à avoir des tests qui valident le code, au lieu d'avoir un code qui valide le test...
C'est totalement à l'inverse de ce qui se fait par exemple dans une stratégie TDD (Test-Driven Development) où le test est écrit avant le code.
0