- Nouveau
- Tendances
- Classement
-
Tagsbonnes-pratiquesBonnes pratiques42teletravailTélétravail15phpPHP14tddTDD13newsletternewsletter13devdev13architectureArchitecture13veilleVeille12design-patternDesign Pattern12agiliteAgilité12codeCode11javascriptJavaScript10devopsDevOps9conferenceConférence8carriereCarrière8retour-d-experienceRetour d'experience7front-endfront-end7gitGit6formationFormation6entreprenariatEntreprenariat6clean-codeClean Code6youtubeYoutube5videoVidéo5programmationprogrammation5podcastPodcast5organisationOrganisation5cultureCulture5testingTesting4tech-leadTech Lead4optimisationOptimisation4freelancingFreelancing4dddDDD4craftCraft4compagnonCompagnon4vue-jsvue.js3retrospectiveRetrospective3remoteremote3reconversionReconversion3programmation-fonctionnelleProgrammation fonctionnelle3productivteproductivté3performancesperformances3nodejsNodeJS3laravelLaravel3javaJava3humourHumour3ethiqueEthique3emploiEmploi3ecologieEcologie3debutantDébutant3cqrsCQRS3covid-19Covid-193clean-architectureClean Architecture3ci-cdCI/CD3blogBlog3architecture-hexagonaleArchitecture Hexagonale3webWeb2vscodevscode2slackSlack2reactReact2pythonPython2produitProduit2pooPOO2personal-brandingpersonal branding2iaIA2hexagonalehexagonale2green-itGreen IT2gestion-du-tempsGestion du temps2evenementÉvènement2ecosystemeEcosystème2donnees-personnellesDonnées personnelles2changelogChangelog2cercleCercle2vite-jsvite.js1visualstudiovisualstudio1vision-systemiqueVision systémique1vie-priveeVie privée1tinydbTinyDB1theorie-des-contraintesThéorie des contraintes1thematuredevTheMatureDev1testtest1systeme-de-queueSystème de queue1sqlSQL1springbootspringboot1slow-techSlow.tech1securiteSécurité1rustrust1restREST1refactoringrefactoring1queerQueer1prodprod1ports-and-adaptersPorts and Adapters1pedagogiePédagogie1pair-programmingPair programming1originesOrigines1open-sourceOpen Source1onlineonline1net.NET1mvcmvc1mutation-testingMutation testing1minimalismeMinimalisme1microsoftmicrosoft1maisonMaison1lowtechLowTech1livelive1licorneLicorne1langagelangage1jobjob1ingenieurieIngénieurie1inclusionInclusion1ideide1hommageHommage1hibernatehibernate1graphqlGraphQL1goGo1flowconFlowcon1flowflow1extreme-programmingeXtreme Programming1event-sourcingEvent sourcing1entretien-d-embaucheEntretien d'embauche1entretienentretien1entrainementEntrainement1energieEnergie1dojoDojo1dockerdocker1diversiteDiversité1devtoolDevTool1dbDB1ctoCTO1csscss1coup-de-gueuleCoup de gueule1cloudCloud1chansonChanson1buildbuild1blazorblazor1bffBFF1bddbdd1avenirAvenir1autonomieAutonomie1audioAudio1atddatdd1apiAPI1androidAndroid1alignementAlignement1algorithmealgorithme1
- Mes favoris
- Recevoir par email
- Partager un lien
Architecture
Bonnes pratiques
Design Pattern
hexagonale
Enocre une ressource sur l'archi hexa, ça fait pas de mal !

Kata Rover avec Guillaume Saint Etienne #1
Accéder à la vidéo
GitHub Vs GitLab
Accéder à l'épisode
Upgrade de carriere avec Maxime Delporte
Accéder à l'épisode
La Rareté Est Un Faux Problème Avec Shirley Almosni Chiche
Accéder à l'épisode
J'aime ce type de pédagogie où l'on suit la réflexion du bonhomme étape par étape, plutôt que de te présenter "simplement le résultat final" en mode "c'est comme ça qu'il faut faire".
Bien écrire ses tests unitaires, c'est tout un art...
Typiquement, dans le cas des tests sur un controlleur, il est très fort probable qu’une même partie de code (un repo, ou un service) soit appelée à chaque fois dans chacun des tests. Dans ce cas, non seulement on test plusieurs fois la même partie de code (ce qui est inutile), mais en plus, si une partie des tests est lente (I/O), alors ceci va avoir un impact sur la durée globale de la suite de test.
Perso, pour contrer ce double problème, je réalise toujours des tests fonctionnels des repositories / services de manière isolés (pour m’assurer de leur comportement), ce qui me permet de les mocker sans craintes lors de mes tests de controlleur.
www.youtube.com/...
Dans le cas expliqué dans la vidéo, il n'y a pas de tests unitaires à proprement parler puisque les tests infrastructure/application sont forcément des tests d'intégrations (application du principe "don't mock what you don't own") et les tests de la couche métier sont forcément des tests fonctionnels puisque l'on teste les cas d'usage.
Et il n'y en a pas d'autre (à part les tests de bout en bout) puisqu'il indique qu'on ne doit tester que les fonctions/méthodes publiques (tout le reste c'est de l'implémentation et on ne teste pas l'implémentation).
Pour moi tout ce qui n'est pas un test de bout en bout est un test unitaire finalement, et on change simplement l'unité que l'on veut tester en fonction du contexte (infrastructure, métier, application).
Est-ce que d'autres personnes font aussi cette distinction ?
Très bonne question, et pour être tout a fait honnête, il y a beaucoup de débat sur la toile sur la définition de chaque terme.
Voici un lien du site de Martin Fowler qui tente de regrouper l’ensemble des tests (martinfowler.com/testing), leurs définitions et leurs usages.
De mon point de vue, en tant que Backend développeur:
Test unitaire: On test uniquement la méthode d’une classe. Si la méthode est dites "pure", on s’assure que pour une entrée X, on a toujours la sortie Y (exemple, une méthode "addition" - si on a en entrée a = 1, et b = 2, alors la sortie doit être 3). Dans le cas où cette méthode fait appel a des services, ces derniers doivent être mocké, on veut simplement s’assurer que le workflow est correct. Si la méthode contient des conditions, chaque cas de condition doit être testé pour s’assurer que le comportement attendu dans chaque est correct.
Test d’intégration: Perso, je mets dans cette catégorie les tests de repositories. Je veux m’assurer que mes requêtes sont correctement formés et qu’elles me retournent les bons résultats si j’ai des conditions pour la création du query builder notamment. En général, je ne mock rien dans ce type de cas de tests.
Test fonctionnel: Il s’agit de tester de manière plus globale une brique fonctionnelle (par exemple, dans le cas d’un service qui serait dédié a la création d’une nouvel utilisateur, on s’assure que les données sont bien enregistrées en base, et que l’on a bien envoyé un email de bienvenue). Bien entendu, on peut mocker certaines parties (comme l’envoi du mail par exemple, puisque ceci est fortement lié à la partie infrastructure, on veut juste s’assurer que l’on est bien passé par le service d’envoi du mail - le fait de l’avoir reçu ou non, ce n’est pas notre responsabilité). Les tests de service complexe rentre selon moi dans cette catégorie.
Test end-to-end: Je vais tester dans cette catégorie tous les composants qui servent de facade a mon application (un controlleur, une commande en ligne, par exemple). Tout comme les tests fonctionnels, certains services peuvent être mockés pour les besoins du tests, mais dans l’idée il en faut le moins possible.
Tout ceci n’est pas à prendre comme argent comptant, c’est la vision que j’en ai à mesure de lire des articles sur ce sujet - et c’est un sujet très vaste...
"Est-ce que d'autres personnes font aussi cette distinction ?"
Personnellement , j'adopte cette définition pour les tests unitaires:
- mono-langage (pas Java + sql par ex)
- mono-couche (pas de métier + I/O par ex)
- répétable (toujours le même résultat)
- rapide (on est en bas de la pyramide des tests)
Tous les tests qui ne répondent pas à cette définition sont des tests d'intégration.
Je n'oppose pas tests fonctionnels et tests unitaires, selon moi on peut trouver des tests fonctionnels unitaires et fonctionnels d'intégration.
La notion de end-to-end est selon moi "variable". Dans des SI suffisamment conséquents, ce qui peu apparaitre à un certain moment comme test e2e (on est au limites du "sous-système" testé), peut dans un cadre plus large être un "simple" test d'intégration (le système est plus large). Cela dépend de la responsabilité de l'équipe en charge / des limites du SI accessible sur un environnement donné.
Je suis d'accord avec @xtrembaker mais je suis peut-être influencé par mon expérience de backend
Cependant je m’interroge sur un point. Il est dit qu’un test unitaire doit se focaliser sur un comportement et non sur la méthode d’une classe. Toutefois, le nombre de bug que j’ai pu éviter, ou que j’ai corrigé, simplement en ajoutant des tests sur des méthodes de classe un peu tricky (calcul, ou conversion par exemple) est innombrable. Si je ne suis pas censé écrire de tests sur la méthode d’une classe, je ne vois pas comment je peux m’assurer qu’elle retourne bien le résultat attendu.
Mais je manque d'arguments et de ressources pour détailler cette nuance :/
Ca te permettra de faire peut etre apparaitre mieux dans ton code un concept métier (si méthode compliqué c'est bien que c'est un point sensible métier normalement)
En le mettant dans une classe dédié, tu pourras aussi le remplacer plus simplement (par exemple ca devient facile de remplacer l'appel de cette classe dédié par une interface et ca ouvre la porte à la possibilité de switcher facilement d'implémentation, imagine que tu as une idée pour améliorer l'algo en question ou améliorer sa vitesse, bim ca devient possible facilement par le fait que tu ai extrait l'algo dans une classe dédié)