Inconvénients du développement piloté par les tests?

Qu’est-ce que je perds en adoptant un design piloté par les tests?

Ne lister que les négatifs; ne listez pas les avantages écrits sous une forme négative.

    Plusieurs inconvénients (et je ne prétends pas qu’il n’ya pas d’avantages – en particulier lors de la rédaction des bases d’un projet – cela permettrait de gagner beaucoup de temps à la fin):

    • Gros investissement. Dans le cas simple, vous perdez environ 20% de la mise en œuvre réelle, mais pour les cas compliqués, vous perdez beaucoup plus.
    • Complexité supplémentaire. Pour les cas complexes, vos cas de test sont plus difficiles à calculer, je suggère dans de tels cas d’essayer d’utiliser un code de référence automatique qui s’exécutera en parallèle dans la version / test de débogage, au lieu du test unitaire des cas les plus simples.
    • Impacts sur la conception Parfois, la conception n’est pas claire au début et évolue au fur et à mesure – cela vous obligera à refaire votre test, ce qui vous fera perdre beaucoup de temps. Je suggère de reporter les tests unitaires dans ce cas jusqu’à ce que vous ayez une idée de la conception en tête.
    • Tweaking continu. Pour les structures de données et les algorithmes de boîtes noires, les tests unitaires seraient parfaits, mais pour les algorithmes qui ont tendance à être modifiés, modifiés ou ajustés, cela peut entraîner un investissement important que l’on pourrait prétendre injustifié. Donc, utilisez-le quand vous pensez qu’il correspond réellement au système et ne force pas la conception à s’adapter à TDD.

    Si vous voulez faire du “vrai” TDD (lisez: testez d’abord avec les étapes rouge, vert, refactor), vous devez également commencer à utiliser des simulations / stubs, lorsque vous voulez tester des points d’intégration.

    Lorsque vous commencez à utiliser des simulacres, après un certain temps, vous souhaiterez commencer à utiliser l’dependency injection (DI) et un conteneur d’inversion de contrôle (IoC). Pour ce faire, vous devez utiliser des interfaces pour tout (qui ont eux-mêmes beaucoup de pièges).

    À la fin de la journée, vous devez écrire beaucoup plus de code que si vous le faites simplement “à l’ancienne”. Au lieu d’une simple classe client, vous devez également écrire une interface, une classe fictive, une configuration IoC et quelques tests.

    Et rappelez-vous que le code de test doit également être maintenu et pris en charge. Les tests doivent être aussi lisibles que tout le rest et l’écriture d’un bon code prend du temps.

    Beaucoup de développeurs ne comprennent pas très bien comment faire tout cela “de la bonne manière”. Mais comme tout le monde leur dit que le TDD est le seul moyen de développer des logiciels, ils essayent simplement de faire de leur mieux.

    C’est beaucoup plus difficile qu’on pourrait le penser. Souvent, les projets réalisés avec TDD se retrouvent avec beaucoup de code que personne ne comprend vraiment. Les tests unitaires testent souvent la mauvaise chose, dans le mauvais sens. Et personne ne convient de la manière dont un bon test devrait ressembler, pas même les soi-disant gourous.

    Tous ces tests compliquent le “changement” (contrairement à la refactorisation): le comportement de votre système et les modifications simples deviennent trop difficiles et prennent trop de temps.

    Si vous lisez la documentation TDD, il y a toujours de très bons exemples, mais dans les applications réelles, vous devez souvent avoir une interface utilisateur et une firebase database. C’est là que TDD devient vraiment difficile, et la plupart des sources n’offrent pas de bonnes réponses. Et si c’est le cas, cela implique toujours plus d’abstractions: objects fictifs, programmation à une interface, motifs MVC / MVP, etc., qui nécessitent encore beaucoup de connaissances et … vous devez écrire encore plus de code.

    Alors soyez prudent … si vous n’avez pas une équipe enthousiaste et au moins un développeur expérimenté qui sait écrire de bons tests et qui connaît également quelques aspects de la bonne architecture, vous devez vraiment réfléchir à deux fois avant de vous lancer sur la route TDD .

    Lorsque vous arrivez à un grand nombre de tests, il peut être nécessaire de réécrire tout ou partie de vos tests, en fonction de ceux qui ont été invalidés par les modifications. Cela pourrait transformer une modification relativement rapide en une très longue période.

    En outre, vous pourriez commencer à prendre des décisions de conception basées davantage sur le TDD que sur les bons responsables de la conception. Alors que vous avez peut-être une solution très simple et facile, impossible à tester de la manière dont TDD exige, vous avez maintenant un système beaucoup plus complexe qui est en fait plus enclin aux erreurs.

    Je pense que le plus gros problème pour moi est la perte de temps énorme qu’il faut pour «y arriver». Je suis encore au début de mon parcours avec TDD (voir mon blog pour les mises à jour de mes aventures de test si cela vous intéresse) et j’ai littéralement passé des heures à démarrer.

    Il faut beaucoup de temps pour mettre votre cerveau en “mode test” et écrire “code testable” est une compétence en soi.

    TBH, respectueusement, je ne suis pas d’accord avec les commentaires de Jason Cohen sur le fait de rendre les méthodes privées publiques, ce n’est pas ce dont il s’agit. Je n’ai plus fait de méthodes publiques que par le passé . Cela implique toutefois des modifications architecturales et vous permet de “twigr” des modules de code pour faciliter tout le test. Vous ne devriez pas rendre les éléments internes de votre code plus accessibles pour ce faire. Sinon, nous revenons à la case départ avec tout ce qui est public, où est l’encapsulation?

    Donc, (OMI) en quelques mots:

    • La quantité de temps pris pour penser
    • Les nouvelles connaissances requirejses pour savoir écrire un code testable.
    • Comprendre les modifications architecturales requirejses pour rendre le code testable.
    • Augmenter vos compétences de “TDD-Coder” tout en essayant d’améliorer toutes les autres compétences requirejses pour notre métier de programmation glorieux 🙂
    • Organiser votre base de code pour inclure le code de test sans vider votre code de production.

    PS: Si vous souhaitez des liens vers des éléments positifs, j’ai demandé et répondu à plusieurs questions, consultez mon profil .

    Dans les quelques années que je pratique le développement piloté par les tests, je dois dire que les plus gros inconvénients sont les suivants:

    Vendre à la direction

    Le TDD se fait mieux par paires. D’une part, il est difficile de résister à l’envie de simplement écrire l’implémentation lorsque vous savez comment écrire une instruction if / else . Mais une paire va vous garder sur la tâche parce que vous le gardez à la tâche. Malheureusement, de nombreuses sociétés / gestionnaires ne pensent pas qu’il s’agit d’une bonne utilisation des ressources. Pourquoi payer deux personnes pour écrire une fonctionnalité, alors que j’ai deux fonctionnalités à faire en même temps?

    La vendre à d’autres développeurs

    Certaines personnes n’ont tout simplement pas la patience d’écrire des tests unitaires. Certains sont très fiers de leur travail. Ou, tout comme les méthodes / fonctions alambiquées se perdent à la fin de l’écran. TDD n’est pas pour tout le monde, mais je le souhaite vraiment. Cela rendrait les choses beaucoup plus faciles pour les pauvres âmes qui héritent du code.

    Maintien du code de test avec votre code de production

    Idéalement, vos tests ne seront rompus que si vous prenez une mauvaise décision de code. C’est-à-dire que vous pensiez que le système fonctionnait dans un sens, et il s’avère que non. En brisant un test, ou un (petit) ensemble de tests, c’est en fait une bonne nouvelle. Vous savez exactement comment votre nouveau code affectera le système. Cependant, si vos tests sont mal écrits, étroitement couplés ou, pire encore, générés ( tousse VS Test), le maintien de vos tests peut rapidement devenir une chorale. Et, après que suffisamment de tests commencent à causer plus de travail que la valeur perçue qu’ils créent, les tests seront alors les premiers à être supprimés lorsque les plannings seront compressés (par exemple, ils auront un temps critique).

    Des tests d’écriture pour tout couvrir (couverture 100% du code)

    Dans l’idéal, encore une fois, si vous respectez la méthodologie, votre code sera testé à 100% par défaut. En règle générale, je me retrouve avec une couverture de code supérieure à 90%. Cela se produit généralement lorsque j’ai une architecture de style modèle et que la base est testée, et j’essaie de couper les coins et de ne pas tester les personnalisations du modèle. De plus, j’ai constaté que lorsque je rencontrais une nouvelle barrière que je n’avais jamais rencontrée auparavant, j’ai une courbe d’apprentissage dans le test. J’admets avoir écrit quelques lignes de code à l’ancienne manière de skool, mais j’aime vraiment avoir ce 100%. (J’imagine que j’étais un excellent élève à l’école, euh skool).

    Cependant, avec cela, je dirais que les avantages de TDD dépassent largement les inconvénients de la simple idée que si vous pouvez réaliser un bon ensemble de tests couvrant votre application mais qui ne sont pas si fragiles qu’un changement les coupe tous, vous pourrez être capable de continuer à append de nouvelles fonctionnalités le jour 300 de votre projet comme vous l’avez fait le jour 1. Cela n’arrive pas avec tous ceux qui essayent TDD en pensant que c’est une solution magique à tout leur code bogue, ne travaille pas, point.

    Personnellement, j’ai trouvé qu’avec TDD, j’écris du code plus simple, je passe moins de temps à discuter si une solution de code particulière fonctionne ou non, et je n’ai aucune crainte de changer une ligne de code qui ne répond pas aux critères définis par l’équipe.

    TDD est une discipline difficile à maîsortingser, et cela fait quelques années que j’y travaille, et j’apprends toujours de nouvelles techniques de test. C’est un investissement de temps énorme, mais, à long terme, votre durabilité sera beaucoup plus grande que si vous n’aviez pas de tests unitaires automatisés. Maintenant, si seulement mes patrons pouvaient le comprendre.

    Sur votre premier projet TDD, il y a deux grandes pertes, le temps et la liberté personnelle

    Vous perdez du temps parce que:

    • La création d’une suite complète, révisée et maintenable de tests unitaires et d’acceptation ajoute un temps important à la première itération du projet. Cela peut être un gain de temps à long terme, mais il peut aussi être temps de ne pas en perdre.
    • Vous devez choisir et devenir expert dans un ensemble d’outils de base. Un outil de test unitaire doit être complété par une sorte de structure de simulation et tous deux doivent faire partie de votre système de génération automatisé. Vous souhaitez également sélectionner et générer des mesures appropriées.

    Vous perdez votre liberté personnelle parce que:

    • TDD est une manière très disciplinée d’écrire du code qui a tendance à se frotter à ceux qui se situent en haut et en bas de l’échelle des compétences. Écrire toujours du code de production d’une certaine manière et soumettre votre travail à un examen continu par les pairs peut faire flipper vos pires et meilleurs développeurs et même entraîner la perte d’effectifs.
    • La plupart des méthodes Agile qui intègrent TDD nécessitent que vous parliez continuellement au client de ce que vous proposez d’accomplir (dans cette histoire / jour / peu importe) et de ce que sont les compromis. Encore une fois, ce n’est pas la tasse de thé de tout le monde, tant du côté des développeurs que des clients.

    J’espère que cela t’aides

    TDD exige que vous planifiiez comment vos classes fonctionneront avant d’écrire du code pour réussir ces tests. C’est à la fois un plus et un moins.

    J’ai du mal à écrire des tests dans un “vide” – avant que tout code n’ait été écrit. Dans mon expérience, j’ai tendance à trébucher sur mes tests chaque fois que je pense inévitablement à quelque chose lorsque j’écris mes cours que j’ai oubliés lors de mes premiers tests. Alors, il est temps non seulement de réorganiser mes cours, mais aussi mes tests. Répétez cette opération trois ou quatre fois et cela peut devenir frustrant.

    Je préfère écrire un brouillon de mes cours puis écrire (et maintenir) une batterie de tests unitaires. Après avoir un brouillon, TDD fonctionne bien pour moi. Par exemple, si un bogue est signalé, je vais écrire un test pour exploiter ce bogue, puis corriger le code pour que le test réussisse.

    Le prototypage peut être très difficile avec TDD – lorsque vous n’êtes pas sûr de la voie à suivre pour trouver une solution, il peut être difficile d’écrire les tests (autres que les tests très larges). Cela peut être une douleur.

    Honnêtement, je ne pense pas que pour le “développement de base” pour la grande majorité des projets, il existe un réel inconvénient; il est beaucoup plus critiqué qu’il ne devrait l’être, généralement par des personnes qui croient que leur code est suffisamment bon pour ne pas avoir besoin de tests (ce n’est jamais le cas) et que les personnes qui ne sont tout simplement pas dignes de les écrire.

    Eh bien, et cet étirement, vous devez déboguer vos tests. En outre, il y a un certain coût en temps pour écrire les tests, bien que la plupart des gens s’accordent à dire qu’il s’agit d’un investissement initial payant tout au long de la durée de vie de l’application.

    Le plus gros problème que j’ai personnellement rencontré, cependant, est de mettre la discipline en pratique pour écrire les tests. Dans une équipe, en particulier une équipe établie, il peut être difficile de les convaincre que le temps passé vaut la peine.

    Vous perdez la capacité de dire que vous êtes “fait” avant de tester tout votre code.

    Vous perdez la possibilité d’écrire des centaines ou des milliers de lignes de code avant de l’exécuter.

    Vous perdez la possibilité d’apprendre grâce au débogage.

    Vous perdez la souplesse nécessaire pour expédier le code dont vous n’êtes pas certain.

    Vous perdez la liberté de coupler étroitement vos modules.

    Vous perdez l’option pour ignorer la documentation de conception de bas niveau.

    Vous perdez la stabilité du code que tout le monde a peur de changer.

    Vous perdez le titre de “pirate”.

    L’inconvénient de TDD est qu’il est généralement étroitement associé à la méthodologie «Agile», qui n’accorde aucune importance à la documentation d’un système, mais plutôt à la compréhension des raisons pour lesquelles un test «devrait» renvoyer une valeur spécifique tête.

    Dès que le développeur quitte ou oublie la raison pour laquelle le test renvoie une valeur spécifique et non une autre, vous êtes vissé. TDD convient bien si elle est correctement documentée et entourée d’une documentation lisible par l’homme (c’est-à-dire avec un gestionnaire pointu) pouvant être consultée dans 5 ans lorsque le monde change et que votre application doit également l’être.

    Lorsque je parle de documentation, il ne s’agit pas d’un texte de présentation codé, il s’agit d’une rédaction officielle externe à l’application, comme des cas d’utilisation et des informations de base pouvant être consultées par les gestionnaires, les avocats votre code en 2011.

    Si vos tests ne sont pas très complets, vous risquez de vous tromper de “tout fonctionne” simplement parce que vos tests réussissent. Théoriquement, si vos tests réussissent, le code fonctionne; mais si nous pouvions écrire du code parfaitement la première fois, nous n’aurions pas besoin de tests. La morale ici est de vous assurer de faire une vérification de santé mentale par vous-même avant d’appeler quelque chose de complet, ne vous fiez pas seulement aux tests.

    Sur cette note, si votre vérification de santé mentale trouve quelque chose qui n’a pas été testé, assurez-vous de revenir en arrière et de rédiger un test.

    J’ai rencontré plusieurs situations où TDD me rend fou. Pour en nommer quelques-uns:

    • Maintenabilité des cas de test:

      Si vous êtes dans une grande entreprise, il y a de grandes chances que vous n’ayez pas à écrire les scénarios de test vous-même ou que la plupart d’entre eux soient écrits par quelqu’un d’autre lorsque vous entrez dans l’entreprise. Les fonctionnalités d’une application changent de temps en temps et si vous n’avez pas de système en place, tel que HP Quality Center, pour les suivre, vous deviendrez fou en un rien de temps.

      Cela signifie également qu’il faudra beaucoup de temps aux nouveaux membres de l’équipe pour saisir ce qui se passe dans les cas de test. En retour, cela peut se traduire par plus d’argent nécessaire.

    • Complexité de l’automatisation des tests:

      Si vous automatisez une partie ou la totalité des scénarios de test dans des scripts de test exécutables par une machine, vous devez vous assurer que ces scripts de test sont synchronisés avec leurs scénarios de test manuels correspondants et en accord avec les modifications de l’application.

      En outre, vous passerez du temps à déboguer les codes qui vous aident à détecter les bogues. À mon avis, la plupart de ces bogues proviennent de l’échec de l’équipe de test à refléter les modifications apscopes à l’application dans le script de test d’automatisation. Des modifications de la logique métier, de l’interface utilisateur graphique et d’autres éléments internes peuvent empêcher vos scripts d’exécuter ou de fonctionner de manière non fiable. Parfois, les changements sont très subtils et difficiles à détecter. Une fois que tous mes scripts ont signalé un échec parce qu’ils ont basé leur calcul sur des informations de la table 1 alors que la table 1 était désormais la table 2 (parce que quelqu’un a échangé le nom des objects de la table dans le code de l’application).

    Le plus gros problème est celui des personnes qui ne savent pas écrire des tests unitaires appropriés. Ils écrivent des tests qui dépendent les uns des autres (et ils fonctionnent très bien avec Ant, mais échouent soudainement quand je les lance depuis Eclipse, simplement parce qu’ils fonctionnent dans un ordre différent). Ils écrivent des tests qui ne testent rien en particulier – ils déboguent simplement le code, vérifient le résultat et le transforment en test, l’appelant “test1”. Ils élargissent la scope des classes et des méthodes, simplement parce qu’il sera plus facile d’écrire des tests unitaires pour eux. Le code des tests unitaires est terrible, avec tous les problèmes de programmation classiques (couplage lourd, méthodes de 500 lignes de long, valeurs codées en dur, duplication de code). Pour des raisons étranges, les gens considèrent les tests unitaires comme inférieurs au code «réel» et ne se soucient pas du tout de leur qualité. 🙁

    Vous perdez beaucoup de temps à écrire des tests. Bien sûr, cela pourrait être enregistré à la fin du projet en attrapant les bogues plus rapidement.

    Le plus gros inconvénient est que si vous voulez vraiment faire du TDD correctement, vous devrez beaucoup échouer avant de réussir. Compte tenu du nombre de sociétés de logiciels qui travaillent (dollar par KLOC), vous finirez par être licencié. Même si votre code est plus rapide, plus propre, plus facile à gérer et contient moins de bogues.

    Si vous travaillez dans une entreprise qui vous paie par les KLOC (ou les exigences implémentées – même si elles ne sont pas testées), restz à l’écart du TDD (ou des revues de code, de la programmation par paires, de l’continuous integration, etc. etc.).

    J’appuie la réponse sur le temps de développement initial. Vous perdez également la capacité de travailler confortablement sans la sécurité des tests. J’ai également été décrit comme un nutbar TDD, vous pouvez donc perdre quelques amis;)

    Recentrer sur des exigences difficiles et imprévues est le fléau constant du programmeur. Le développement piloté par les tests vous oblige à vous concentrer sur les exigences courantes et connues, et limite votre développement à ce qui a déjà été imaginé.

    Pensez-y, vous allez probablement finir par concevoir des cas de test spécifiques, afin de ne pas être créatif et de commencer à penser “ce serait cool si l’utilisateur pouvait faire X, Y et Z”. Par conséquent, lorsque cet utilisateur commence à s’intéresser aux exigences X, Y et Z potentielles, il se peut que votre conception se concentre trop rigoureusement sur des cas de test déjà spécifiés et qu’il sera difficile à ajuster.

    Ceci, bien sûr, est une épée à double tranchant. Si vous consacrez tout votre temps à concevoir pour chaque imaginable, imaginable, X, Y et Z qu’un utilisateur puisse souhaiter, vous ne finirez jamais jamais quoi que ce soit. Si vous complétez quelque chose, il sera impossible à quiconque (y compris vous-même) d’avoir une idée de ce que vous faites dans votre code / conception.

    C’est perçu comme plus lent. À long terme, ce n’est pas vrai en termes de chagrin, mais vous finirez par écrire plus de code, donc vous passez du temps à “tester sans coder”. C’est un argument erroné, mais vous avez demandé!

    Il peut être difficile et fastidieux d’écrire des tests pour des données “aléatoires” telles que les stream XML et les bases de données (pas si difficiles). Récemment, j’ai travaillé avec des stream de données météorologiques. Ce sont des tests d’écriture assez déroutants pour cela, du moins parce que je n’ai pas trop d’expérience avec TDD.

    Vous allez perdre de grandes classes avec de multiples responsabilités. Vous risquez également de perdre de grandes méthodes avec de multiples responsabilités. Vous risquez de perdre une certaine capacité de refactorisation, mais vous perdrez également une partie du besoin de refactorisation.

    Jason Cohen a dit quelque chose comme: TDD nécessite une certaine organisation pour votre code. Cela peut être architecturalement faux; Par exemple, comme les méthodes privées ne peuvent pas être appelées en dehors d’une classe, vous devez rendre les méthodes non privées pour les rendre testables.

    Je dis que cela indique une abstraction manquée – si le code privé doit vraiment être testé, il devrait probablement être dans une classe distincte.

    Dave Mann

    Vous devez écrire des applications d’une manière différente: une qui les rend testables. Vous seriez surpris de voir à quel point c’est difficile au début.

    Certaines personnes trouvent l’idée de penser à ce qu’elles vont écrire avant de l’écrire trop fort. Des concepts tels que la moquerie peuvent être difficiles pour certains. TDD dans les applications héritées peut être très difficile si elles n’ont pas été conçues pour des tests. TDD autour de frameworks qui ne sont pas compatibles TDD peut aussi être un combat.

    TDD est une compétence que les développeurs juniors peuvent avoir au début (principalement parce qu’ils n’ont pas appris à travailler de cette façon).

    Dans l’ensemble, les inconvénients sont résolus au fur et à mesure que les gens deviennent qualifiés et que vous finissez par supprimer le code «malodorant» et que votre système est plus stable.

    Il faut un certain temps pour y arriver et un peu de temps pour commencer à le faire dans un projet mais … Je regrette toujours de ne pas avoir recours à une approche testée lorsque je trouve des bugs stupides qu’un test automatisé aurait pu trouver très rapidement. De plus, TDD améliore la qualité du code.

    • test unitaire sont plus de code à écrire, donc un coût initial de développement plus élevé
    • c’est plus de code à maintenir
    • apprentissage supplémentaire requirejs

    Bonnes réponses à tous. J’appendais quelques moyens d’éviter le côté obscur de TDD:

    • J’ai écrit des applications pour faire leur propre autotest aléatoire. Le problème avec l’écriture de tests spécifiques est que même si vous écrivez beaucoup d’entre eux, ils ne couvrent que les cas auxquels vous pensez. Les générateurs de tests aléatoires trouvent des problèmes auxquels vous n’avez pas pensé.

    • Le concept entier de nombreux tests unitaires implique que vous avez des composants qui peuvent entrer dans des états non valides, comme des structures de données complexes. Si vous restz à l’écart des structures de données complexes, il y a beaucoup moins à tester.

    • Dans la mesure où votre application le permet, ne soyez pas attentif à la conception qui repose sur le bon classement des notifications, des événements et des effets secondaires. Celles-ci peuvent facilement être supprimées ou brouillées, ce qui nécessite de nombreux tests.

    TDD nécessite une certaine organisation pour votre code. Cela peut être inefficace ou difficile à lire. Ou même architecturalement mal; Par exemple, comme private méthodes private ne peuvent pas être appelées en dehors d’une classe, vous devez rendre les méthodes non privées pour les rendre testables, ce qui est tout simplement faux.

    Lorsque le code change, vous devez également modifier les tests. Avec le refactoring, cela peut représenter beaucoup de travail supplémentaire.

    Permettez-moi d’append que si vous appliquez les principes BDD à un projet TDD, vous pouvez réduire certains des inconvénients majeurs énumérés ici (confusion, malentendus, etc.). Si vous n’êtes pas familier avec BDD, vous devriez lire l’introduction de Dan North. Il a proposé le concept en réponse à certaines des questions soulevées par l’application du TDD sur le lieu de travail. L’introduction de Dan sur BDD se trouve ici .

    Je ne fais cette suggestion que parce que BDD traite certains de ces points négatifs et agit comme un écart. Vous voudrez en tenir compte lors de la collecte de vos commentaires.

    Vous devez vous assurer que vos tests sont toujours à jour, au moment où vous commencez à ignorer les feux rouges, c’est le moment où les tests deviennent sans signification.

    Vous devez également vous assurer que les tests sont complets, ou au moment où un gros bogue apparaît, le type de gestion étouffant que vous avez finalement convaincu de vous laisser passer du temps à écrire plus de code vous déplaira.

    La personne qui a enseigné le développement agile à mon équipe ne croyait pas à la planification, vous avez seulement écrit autant pour le plus petit besoin.

    Sa devise était refactor, refactor, refactor. J’ai compris que refactor signifiait «ne pas planifier à l’avance».

    Le temps de développement augmente: chaque méthode nécessite des tests et si vous avez une grande application avec des dépendances, vous devez préparer et nettoyer vos données pour les tests.