Salut;
Pour la méthode TDD, qui consiste à réaliser des tests avant le code.Ma question est comment écrire la squolette de code de test avnt meme code r l'application. y'a t'il un scénario de test réutilisable pour tout projet?
MErci bien:lol:
Version imprimable
Salut;
Pour la méthode TDD, qui consiste à réaliser des tests avant le code.Ma question est comment écrire la squolette de code de test avnt meme code r l'application. y'a t'il un scénario de test réutilisable pour tout projet?
MErci bien:lol:
Un tel scénario n'existe pas. Par contre il y a des patrons (patterns) repertoriés pour des problématiques de test courantes. Voir en particulier le livre http://xunitpatterns.com/Citation:
Envoyé par taroudant
Bruno
Comment donc mettre en place un Design Pattern général utilisable pour n'importe quel framework de test unitaire?
j'avoue ne pas comprendre la question. Quel est le but recherché ?Citation:
Envoyé par taroudant
Bruno
Je comprends ta surprise à l'idée d'écrire les tests avant d'avoir écrit le code. Mais en fait, l'idée est la suivante.
Dans une expression de besoin, tu énumères ce dont tes utilisateurs/demandeurs ont besoin.
Dans l'analyse fonctionnelle qui suivra, tu diras comment tu comptes d'y prendre, de manière théorique, pour répondre à leur problème. Règles de gestion, objets impliqués, services contactés. Mais dans ce document, tu n'auras pourtant pas parlé du code qui se trouvera dedans: du Java, du C++, du VB ? Ce n'est pas important. Ton souhait, c'était de présenter le problème clairement et de dire comment il fallait le résoudre, de manière théorique.
Donc, ton analyse fonctionnelle te dira des choses comme: si tu transmets deux objets à un service, tu en recevras un, pour peu que tu aies respecté des règles de gestion..
Par exemple, l'analyse fonctionnelle dit:
Si je donne un euro à la boulangerie, et que je lui demande une baguette de pain, elle me la donnera. Que je dois veiller à ce qu'elle soit ouverte pour cela, bien entendu.
Les objets Monnaie, Baguette seront mis en jeu. Le service s'appellera Boulangerie et la fonction que j'appellerai chez lui s'appellera achat.
Qu'importe le langage que j'utiliserai!
Ce que je sais c'est que:
- si la boulangerie est fermée, ça ne devrait pas marcher.
- si elle est ouverte mais que je ne demande pas une baguette, non plus.
- si elle est ouverte, que je demande une baguette mais ne donne pas assez d'argent, ça ne passera pas plus.
- si elle est ouverte, que je donne assez d'argent et demande une baguette, là, je dois l'avoir.
Donc, je crée des objets Baguette et Monnaie, ainsi qu'un service Boulangerie qui auront tous des variables membres nulles et des méthodes ne faisant rien... et qui échoueront toujours au début. Mais ils me permettront d'écrire mes méthodes de test. Et plus mon projet, ensuite, se réalisera, et plus les méthodes des objets seront complétées et les tests passeront.
Un test: "si je demande une baguette mais ne donne pas assez d'argent, ça ne marche pas".
Code:
2
3
4
5
6
7
8
9
10
11
12try { Monnaie m = new Monnaie(0.90, "EURO"); Baguette b = boulangerie.achat("baguette", m); fail(); // Passage normal => échec. } catch(PaiementInsuffisantException e) { // Sous-entendu: réussite du test. }
Dans mon projet, j'ai créé les objets Monnaie, Baguette et Boulangerie frustres.
et:Code:
2
3
4
5
6
7
8
9
10
11
12class Monnaie { Monnaie(double quantité, String devise) {} double quantité() {return 0;} String devise() {return null;} } class Baguette { Baguette() {} }
Ces objets ne vont rien amener de bon au début.Code:
2
3
4
5
6
7
8class Boulangerie { Baguette achat(String szDemande, Monnaie m) throws PaiementInsuffisantException { return(null); } }
En ce qui concerne notre test, il ne réussira pas. Car la monnaie créée ne tient aucun compte du montant annoncé dans le constructeur ni de sa devise. Les pointeurs nuls vont pleuvoir! Et même plus tard, la boulangerie renvoyant null, on aura ni baguette ni exception, alors...
Alors quoi? C'est des tests, et ils compilent. Et ils ont été écrits avant le code source final de l'application. C'est tout ce que l'on demandait.
Maintenant, il n'y a plus qu'à coder les classes Monnaie, Baguette, Boulangerie jusqu'à ce que ces tests deviennent "verts". C'est à dire: qu'ils passent.