Découvrir Eclipse

Progresser avec TDD

Testez gratuitement nos 1257 formations

pendant 10 jours !

Tester maintenant Afficher tous les abonnements
Eclipse intègre l'utilisation de la bibliothèque Junit, qui est accessible simplement et qui s'exécute dans le cadre de interface Eclipse.

Transcription

Dans cette vidéo, nous allons chercher à progresser avec le TDD, le «Test Driven Development» grâce à un outil comme Eclipse. Je vais créer un nouveau projet Java Project que je vais appeler «exercice33», dans lequel je vais créer un «source folder» qui va s'appeler «test» et va contenir mes tests. Je vais utiliser JUnit pour réaliser mon test, donc je vais d'abord créer un «JUnit Test Case». Cette classe de test va réaliser des tests sur ce qu'on appelle un fichier. Dans cette classe qui représente les tests, je vais tester les différentes vérités sur un système de fichiers. Je vais écrire ici que dans le test de fichier, je peux construire un objet fichier, comme cela : «Fichier fichier = new Fichier». Il est prévu dans ma «to do list» qu'un fichier ait un nom. Je vais créer un fichier avec un nom et vérifier ensuite si le nom de ce fichier est bien égal à «.equals» : non. Je peux réaliser mon test comme cela. Les insertions me permettront juste d'avoir une barre rouge ou verte. Il faut construire le test un peu différemment, par exemple «String nom =» et je donne une chaîne de caractère «nom». Je passe cette chaîne de caractère dans la construction du fichier et je peux tester l'égalité du nom. Plutôt que «assertTrue» avec «equals» vous avez directement dans «class assert» un «assertEquals». Vous passez la valeur que vous attendez, la valeur réelle et il va vous dire si les deux valeur sont égales. Évidemment, la première fois que je lance ce test, je vais obtenir une erreur car le fichier n'existe pas et ne se compile pas. Je vais donc créer ma classe «fichier», dans «src» bien sûr et pas dans «test», comme ceci. J'ai besoin de créer un constructeur de fichier, comme cela, et j'ai besoin que «getNom» existe, comme ceci. Maintenant que j'ai généré le code dans la classe «fichier», je sauvegarde tout cela. A priori, plus d'erreur de compilation : il est temps de faire le test. Le test ne passe pas : j'ai besoin de le faire passer. Pour faire passer le test, je vais venir ici. Ce que je vais faire, en gros, c'est tout simplement un «return "nom"» ici, de façon à satisfaire mon test. Si ce code peut paraître idiot, il a réussi à faire passer le test. Dans un deuxième temps, une fois arrivé là, je dois faire du «refactoring», c'est-à-dire rendre mon code plus intelligent, améliorer sa conception. Il est clair qu'un fichier doit conserver le nom qu'on lui passe, donc «this.nom=nom» et ici «return» évidemment, de l'attribut. Sans cette étape de refactoring, cette approche «test first» qu'on utilise dans le TDD est un peu ridicule. Je vais relancer mon test et vérifier que rien n'a changé. L'intérêt de disposer d'une batterie de tests pour le refactoring, c'est de pouvoir modifier le code interne de la classe «fichier» et que le test continue de passer, comme on le voit ici. Vous n'avez pas à reprendre les tests pour modifier la classe «fichier». Tout cela milite en faveur des tests «boîte noire», c'est-à-dire ne pas tester l'interne du fichier mais son comportement apparent. Pour continuer avec le TDD, il faudrait construire d'autres tests concernant le fichier. Un fichier a une taille, il peut être placé dans un dossier, je peux créer un dossier avec un nom, je peux créer des liens, etc. Je fais avancer mon code de cette façon, petit à petit. Pour livrer ensuite le projet, je ne livrerai que ce qui se trouve dans le répertoire «src». Ce qui se trouve dans le répertoire «test» n'a pas à être livré. J'ai séparé physiquement grâce à Eclipse, dans deux source folders, les sources de mes deux classes. «TestFichier», j'ai dit qu'on n'avait pas besoin de le livrer. En fait, on le livre en général, mais il ne fait pas partie des livrables au coeur de l'application sur laquelle je travaille. Ce travail par TDD est facilité par l'usage d'un framework comme JUnit. Il reste évidemment des classes plus difficiles à tester, par exemple les classes d'IHM ou bien lorsque l'application nécessite une certaine instrumentation, comme les classes qu'on va développer pour des applications Android.

Découvrir Eclipse

Voyez comment réaliser vos projets de développement Java avec Eclipse. Facilitez-vous la vie avec la prise en charge des tests, les composants additionnels, etc.

2h12 (28 vidéos)
Aucun commentaire n´est disponible actuellement
 
Logiciel :
Eclipse Eclipse 4.6
Spécial abonnés
Date de parution :26 juil. 2016

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !