Visionnez la vidéo ici même ou directement sur YouTube en cliquant sur le lien.
Attention : vérifiez que la qualité de lecture est d'au moins 480p pour que le code soit lisible ! et passez en plein écran pour en profiter pleinement.
N'hésitez pas à poster vos questions ou remarques ci-dessous, ou à me contacter pour plus de renseignements ! Merci
Le code source de la session live des Human Talks :
https://github.com/xnopre/tdd-htgrenoble-2013.04.09
Les slides :
Quelques retours rapides.
RépondreSupprimer- J'ai tendance à différentier TDD de Test First. Le TDD est à mon sens pas forcément du Test First, il s'agit d'appuyer le design du code sur les tests dans une approche bottom-up, et afin d'avoir, pour chaque ligne de code écrite, un résultat démontrable (i.e. test).
- Pour les assertions, j'ai tendance à préférer partir sur du hamcrest ou un autre framework. Je trouve que ça rend les tests plus expressifs. Par ailleurs, ça permet de créer des matchers pour tes besoins (ton assertRationnalEquals par exemple). L'avantage de hamcrest est qu'il est embarqué directement dans Junit4
Pour le futur, ce qui pourrait être pas mal c'est les sujets suivants (liste non exhaustive bien sûr ;)) :
- le TDD sur les interfaces graphiques ?
- cas d'une application existente non testée et non designée pour les tests
- comment l'architecture d'une application évolue (niveau classe, package, module, ...)
- cas des API qui évoluent
- Quand faire du test unitaire et du test d'intégration (bien que ça sorte un peu du sujet)
Quelques autres retours :
Supprimer- Quand et comment utiliser les mocks ? En particulier, comment mocker des dépendances sans savoir comment elles seront invoquées ?
- Quid de la couverture de code par rapport à la couverture des entrées : quand est-ce que l'on s'arrête ?
- Et à nouveau sur les UI : quelles stratégies utiliser
Salut Frédéric,
SupprimerMerci pour tous ces retours ! Quelques réponses :
- "Test First" : bien sûr que le TDD n'est pas que du "Test First", mais dans une phase de découverte, comme celle de cette vidéo, pour moi, ça commence par là, écrire d'abord les tests, et les impacts sur le design du code viendront naturellement, mais par la suite
- d'ailleurs j'irai plus loin : on ne devrait plus parler de "tests unitaires" et de "TDD" mais simplement ... de "développement" (ces éléments en font partie) !
- hamcrest : je ne l'utilise pas trop, j'utilise pas mal Fest (https://code.google.com/p/fest/) qui est embarqué avec Play 1 ! ;-)
Merci pour les autres questions qui sont autant d'idées pour d'éventuels futurs codecast ! ....
Certains sujets pourraient être abordés prochainement : utilisation de JUnit et autres frameworks de tests, les mocks, etc ... La base quoi !
D'autres de tes questions concernent des situations fréquemment rencontrées, mais qu'on se le dise, sont également des situations plus difficiles. Donc en attendant, quelques conseils :
- les tests sur du code existant ("legacy") sont possibles mais sont difficiles et nécessitent déjà une certaine maîtrise, donc commencez sur du code nouveau !
- les test d'IHM sont souvent coûteux (à mettre en place et à maintenir) et souvent avec un mauvais ROI ("Return On Invest" = Retour sur Investissement) : commencez par sortir tous les traitements dans des classes où vous pourrez les tester unitairement de façon plus classique (ce sera déjà ça, pour commencer)
Encore merci pour tes retours et ton soutien !
A suivre ... (peut-être) ...
Quelques précisions suite aux retours et questions que j'ai reçus :
RépondreSupprimer- pour cette introduction, j'utilise les assertions de JUnit 4, mais il existe des frameworks qui permettent d'être plus lisibles et "fluent" (Fest ou hamcrest)
- mon Eclipse est équipé de Infinitest (http://infinitest.github.io/) désactivé pour la démo pour bien montrer, en manuel, le cycle TDD et les moments où je lance les tests
- notez que la méthode "gcd" n'est pas testée directement mais bien par le résultat qu'elle produit (= tests des méthodes publiques uniquement, nous en reparlerons ...)
N'hésitez pas à me faire des retours, suggestions, questions, remarques, etc ... qui pourraient être autant de thèmes pour d'éventuels futurs codecasts, si ça intéresse du monde ...
Merci
Merci pour ce CodeCast !
RépondreSupprimerLe message passe très bien, et j'aime bien le format court/rapide de 10mn.
Juste pour info, tu as utilisé quel outil pour faire le codecast?
(et sur quelle machine/OS es-tu?)
Laurent
Salut Laurent,
RépondreSupprimerMerci pour ton retour.
Le format de 10' est imposé par les Human Talks. J'ai voulu refaire et enregistrer ce défi que je m'étais lancé, notamment pour les absents. Mais c'est vrai que c'est un bon format pour des codecasts : pour le visiteur, pas besoin de dégager beaucoup de temps pour le visionner, mais pour moi, c'est quand même court et rapide, et ça voudrait dire faire plein de codecasts pour couvrir les thèmes et questions à aborder ...
Question outil, j'ai utilisé CamStudio sous Windows 7, ça marche pas mal après quelques réglages.
Xavier
Super démo Xavier! Rapide mais clair.
RépondreSupprimerMerci Johan, tout comme toi (http://martinsson-johan.blogspot.fr/2013/04/developpeurs-anonymes-mixit.html), je pense qu'il nous faut partager le plus possible ces valeurs et ces approches qui nous tiennent à cœur et font que notre métier est une passion !
SupprimerJe prends le temps pour un retour un peu plus détaillé
RépondreSupprimerOn avait discuté des cycles TDD là où toi tu faisais un test entier puis implem et moi je faisais des plus petites étapes, ce que j'aurais probablement fait dans le cas précis du add() est de faire d'abord l'assert sur "numer" -> code -> vert -> assert "denom" etc. Maintenant je suis parfaitement à l'aise qu'on ne fasse pas comme moi :) Je voulais juste saisir l'opportunité de préciser ce que je voulais dire par plus petites étapes.
Ensuite cette exercise force à écrire des tests pas très progressifs. Il y a 4 tests pour 4 points d'entrée qui chacun est implementé d'un coup, au lieu de plusieurs tests tapant sur la même fonction le faisant émerger de facon incrementale. Ca a du sens ce que je dis?