Je pense honnêtement que le début passe à côté des plus gros intérêts des TU, et en particulier que le tableau est faux. S’ils sont commités avec le code, des tests faits avec des main peuvent tout à fait être reproductibles, compréhensibles et documentés – j’ai même croisé un très vieux projet avec plus de 500 main de test dedans. Par contre, c’est ultra pénible parce que c’est spécifique au projet, éparpillé, mélangé avec le code de production, difficile à découvrir et surtout, surtout, impossible à lancer en tant que « suite de tests ». Ça ne produit pas non plus de rapports standards à intégrer dans un flux de travail sain (intégration continue, etc).
Pour moi il manque aussi une notion importante : avoir des TU, c’est aussi faire en sorte que le code soit architecturé de façon à être testable. Toute personne qui a tenté d’ajouter des tests à postériori sur un code historique voit très bien ce dont je veux parler.
Pas encore pris en compte, ça viendra, mais je veux me poser pour bien faire ça.
Pinaillage : JUnit est un framework de test de Java, pas le seul existant.
Fixed
Pour l’installation, ça serait pas mal de renvoyer vers les documentation pour Maven et Gradle.
Je verrai comment faire.
Je ne vois vraiment pas l’intérêt de présenter les tests avec fail(), je ne connais personne qui fait ça – de fait, l’utilisation de fail() en-dehors du cas d’un test pas encore implémenté est très rare. Pour moi il vaut mieux présenter directement les assertions avec les méthodes assertXXX(), parce que ça correspond bien mieux à ce qui se fait (donc évite de commencer par apprendre quelque chose d’inutilisé), et surtout permet de montrer dès le début qu’une méthode de test peut être simple (c’est important pour faire accepter l’idée de passer du temps à faire des tests).
J’ai totalement revamp cette partie là. Je pense que ça permet d’aller petit à petit vers le concept sans jeter fonctions que le débutant ne peut pas deviner de suite ni pourquoi elles sont là.
Pourquoi ce paragraphe est sur Eclipse et pas sur IntelliJ ?
Car je n’ai pas encore eu le temps de le reprendre, comme je le disais, je n’ai pu revamp qu’une toute petite partie du tuto et que pour moi le coverage n’a pas sa place aussi tôt dans le tuto.
Je ne sais pas si c’est pertinent de présenter les mocks comme étant des implémentations ad hoc des interfaces. Je n’ai jamais vu personne faire ça dans toute ma carrière (je le vois très souvent sur des interfaces extérieures au programme – typiquement les entrées/sorties –, mais jamais sur les interfaces Java au sein du projet). Par contre, présenter directement des outils comme Mockito peut être trop difficile.
Le chapitre des mocks DOIT être revamp, ne serait-ce que parce qu’il passe à côté de cette si loufoque et géniale traduction francophone "le bouchonnage".
Blague a part, le tutoriel initial est vieux, je le reprends car j’aime pas trop l’idée de perdre le référencement, mais certaines parties seront jetées et refaites alors que sur d’autres je vais par exemple garder la trame voire les idées d’exemples.
