Débuter le TDD – Défis ?Solutions?Des recommandations ?[fermé]

StackOverflow https://stackoverflow.com/questions/24965

Question

OK, je sais qu'il y a déjà eu des questions sur débuter avec TDD..Cependant, je suppose que je sais que le consensus général est de fais-le , Cependant, il me semble avoir les problèmes suivants pour me lancer dans le jeu :

  • Lorsque vous travaillez avec des collections, les tests d'ajout/suppression/insertion évidents sont-ils toujours réussis, même lorsqu'ils sont basés sur des génériques, etc., où nous "savons" en quelque sorte que cela va fonctionner ?
  • Certains tests semblent prendre une éternité à mettre en œuvre.Par exemple, lorsque vous travaillez avec une sortie de chaîne, existe-t-il une « meilleure » ​​façon de procéder pour ce genre de choses ?(par exemple.testez le modèle objet avant l'analyse, divisez l'analyse en petites opérations et testez-y) Dans mon esprit, vous devriez toujours tester le "résultat final", mais cela peut varier énormément et être fastidieux à configurer.
  • Je n'ai pas de cadre de test à utiliser (le travail ne paiera pas pour un) donc je peux « m'entraîner » davantage.Y en a-t-il de bons qui sont gratuits pour un usage commercial ?(en ce moment j'utilise du bon vieux Déboguer.Assert :)
  • Probablement le plus gros..Parfois je ne sais pas à quoi m'attendre PAS se passer..Je veux dire, vous obtenez votre feu vert mais j'ai toujours peur de rater un test.Creusez-vous plus profondément pour essayer de casser le code, ou laissez-le tel quel et attendez que tout tombe plus tard (ce qui coûtera plus cher).

Donc fondamentalement, ce que je recherche ici n'est pas un " fais-le " mais plus " J'ai fait ça, j'ai eu des problèmes avec ça, je les ai résolus par ça "..Le personnel expérience :)

Était-ce utile?

La solution

Premièrement, il est normal et normal de se sentir frustré lorsque vous commencez à essayer d'utiliser TDD dans votre style de codage.Ne vous découragez pas et n’arrêtez pas, vous devrez lui donner du temps.Il s’agit d’un changement de paradigme majeur dans la manière dont nous envisageons la résolution d’un problème de code.J'aime y penser comme lorsque nous sommes passés de la programmation procédurale à la programmation orientée objet.

Deuxièmement, je pense que le développement piloté par les tests est avant tout une activité de conception qui sert à étoffer la conception d'un composant en créant un test qui décrit d'abord l'API qu'il va exposer et comment vous allez utiliser ses fonctionnalités.Le test aidera à façonner et à modeler le système testé jusqu'à ce que vous soyez en mesure d'encapsuler suffisamment de fonctionnalités pour satisfaire toutes les tâches sur lesquelles vous travaillez.

En gardant à l’esprit le paragraphe ci-dessus, examinons vos questions :

  1. Si j'utilise une collection dans mon système en cours de test, je configurerai une attente pour m'assurer que le code a été appelé pour insérer l'élément, puis affirmer le nombre de la collection.Je ne teste pas forcément la méthode Add sur ma liste interne.Je m'assure simplement qu'il a été appelé lorsque la méthode qui ajoute l'élément est appelée.Je fais cela en ajoutant un framework moqueur au mix, avec mon framework de test.
  2. Tester les chaînes en sortie peut être fastidieux.Vous ne pouvez pas rendre compte de chaque résultat.Vous ne pouvez tester que ce que vous attendez en fonction des fonctionnalités du système testé.Vous devez toujours décomposer vos tests en fonction du plus petit élément testé.Ce qui signifie que vous aurez beaucoup de tests, mais des tests petits et rapides qui ne testeront que ce qu'ils devraient, rien d'autre.
  3. Il existe de nombreux frameworks de test open source parmi lesquels choisir.Je ne vais pas discuter de ce qui est le mieux.Trouvez-en simplement un que vous aimez et commencez à l’utiliser.
  4. Tout ce que vous pouvez faire est de configurer vos tests pour tenir compte de ce que vous voulez qu'il se passe.Si un scénario apparaît qui introduit un bug dans votre fonctionnalité, vous disposez au moins d'un test autour de la fonctionnalité pour ajouter ce scénario dans le test, puis modifiez votre fonctionnalité jusqu'à ce que le test réussisse.Une façon de savoir où nous avons pu manquer un test est d'utiliser couverture de code.

Je vous ai présenté le terme moqueur dans la réponse à la première question.Lorsque vous introduisez la moquerie dans votre arsenal pour TDD, cela facilite considérablement les tests en éliminant les parties qui ne font pas partie du système testé.Voici quelques ressources sur les frameworks moqueurs disponibles :

Une façon d'aider à utiliser le TDD, outre la lecture du processus, est de regarder les gens le faire.Je recommande de regarder les screencasts de JP Boodhoo sur DNRTV.Découvrez-les :

OK, cela vous aidera à voir comment les termes que j'ai introduits sont utilisés.Il introduira également un autre outil appelé Affûteur et comment cela peut faciliter le processus TDD.Je ne saurais trop recommander cet outil lorsque je fais du TDD.On dirait que vous apprenez le processus et que vous découvrez simplement certains des problèmes qui ont déjà été résolus en utilisant d'autres outils.

Je pense que je ferais une injustice à la communauté si je ne mettais pas cela à jour en ajoutant la nouvelle série de Kent Beck sur Développement piloté par les tests sur Pragmatic Programmer.

Autres conseils

D'après ma propre expérience:

  1. Testez uniquement votre propre code, pas celui du framework sous-jacent.Donc, si vous utilisez une liste générique, il n'est pas nécessaire de tester Ajouter, Supprimer, etc.

  2. Il n'y a pas de 2.Regarde là-bas!Singes!!!

  3. NUnité est la voie à suivre.

  4. Vous ne pouvez certainement pas tester tous les résultats.Je teste ce à quoi je m'attends, puis je teste quelques cas extrêmes dans lesquels je m'attends à obtenir des exceptions ou des réponses invalides.Si un bug survient à cause de quelque chose que vous avez oublié de tester, la première chose à faire (avant d'essayer de corriger le bug) est d'écrire un test pour prouver que le bug existe.

Mon point de vue à ce sujet est le suivant :

  • +1 pour ne pas tester le code du framework, mais vous devrez peut-être quand même tester les classes dérivées des classes du framework.
  • Si une classe/méthode est difficile à tester, cela peut être une forte indication que quelque chose ne va pas avec la conception.J'essaie de suivre le principe "1 classe - 1 responsabilité, 1 méthode - 1 action".De cette façon, vous pourrez tester des méthodes complexes beaucoup plus facilement en le faisant par petites portions.
  • +1 pour xUnit.Pour Java, vous pouvez également envisager TestNG.
  • TDD n'est pas un événement unique, c'est un processus.N'essayez donc pas de tout imaginer depuis le début, mais assurez-vous que chaque bug trouvé dans le code est réellement couvert par le test une fois découvert.

Je pense que la chose la plus importante (et en fait l'un des grands résultats, de manière quelque peu récursive), de TDD est une gestion réussie des dépendances.Vous devez vous assurer que les modules sont testés de manière isolée, sans qu'aucune configuration complexe ne soit nécessaire.Par exemple, si vous testez un composant qui envoie finalement un e-mail, faites de l'expéditeur de l'e-mail une dépendance afin de pouvoir vous en moquer dans vos tests.Cela nous amène à un deuxième point : les moqueurs sont vos amis.Familiarisez-vous avec les frameworks moqueurs et le style de tests qu'ils promeuvent (comportementaux, par opposition aux tests classiques basés sur l'état), ainsi que les choix de conception qu'ils encouragent (The "Dis, ne demande pas" principe).

J'ai trouvé que les principes illustrés dans le Trois fiches pour mémoriser facilement l'essence du TDD est un bon guide.

Quoi qu'il en soit, pour répondre à vos questions

  1. Vous n'êtes pas obligé de tester quelque chose dont vous « savez » qu'il fonctionnera, à moins que vous ne l'ayez écrit.Vous n'avez pas écrit de génériques, Microsoft l'a fait ;)
  2. Si vous devez en faire autant pour votre test, peut-être que votre objet/méthode en fait trop également.
  3. Télécharger TestDriven.NET pour démarrer immédiatement les tests unitaires sur votre Visual Studio (sauf s'il s'agit d'une édition Express)
  4. Testez simplement le c'est la bonne chose qui va arriver.Tu ne le fais pas besoin pour tester tout ce qui peut mal se passer :vous devez attendre que vos tests échouent pour cela.

Sérieusement, fais-le, mec.:)

Je ne suis en aucun cas un expert du TDD, mais voici mon point de vue :

  • Si c'est complètement trivial (getters/setters, etc.), ne le testez pas, sauf si vous n'avez pas confiance dans le code pour une raison quelconque.
  • S’il s’agit d’une méthode assez simple mais non triviale, testez-la.Le test est probablement facile à écrire de toute façon.
  • En ce qui concerne ce à quoi il faut s'attendre, je dirais que si un certain problème potentiel relève de la responsabilité de la classe que vous testez, vous devez tester qu'elle le gère correctement.Si ce n'est pas la responsabilité de la classe actuelle, ne la testez pas.

Les frameworks de test xUnit sont souvent gratuits, donc si vous êtes un utilisateur .Net, consultez NUnit, et si Java est votre truc, consultez JUnit.

Les conseils ci-dessus sont bons, et si vous voulez une liste de frameworks gratuits, vous ne devez pas chercher plus loin que le Liste des frameworks xUnit sur Wikipédia.J'espère que cela t'aides :)

À mon avis (votre kilométrage peut varier) :

1- Si vous ne l'avez pas écrit, ne le testez pas.Si vous l'avez écrit et que vous n'avez pas de test, il n'existe pas.

3- Comme tout le monde le dit, xUnit est gratuit et génial.

2 & 4- Décider exactement quoi tester est l'une de ces choses dont vous pouvez débattre avec vous-même pour toujours.J'essaie de tracer cette ligne en utilisant les principes du design by contract.Consultez « Construction de logiciels orientés objet » ou « Le programmeur pragmatique » pour plus de détails à ce sujet.

Gardez les tests courts, "atomiques".Testez la plus petite hypothèse dans chaque test.Rendre chaque TestMethod indépendant, pour les tests d'intégration, je crée même une nouvelle base de données pour chaque méthode.Si vous devez créer des données pour chaque test, utilisez une méthode "Init".Utilisez des simulations pour isoler la classe que vous testez de ses dépendances.

Je me demande toujours "quelle est la quantité minimale de code que je dois écrire pour prouver que cela fonctionne dans tous les cas ?"

Au cours de la dernière année, je suis devenu de plus en plus convaincu des avantages du TDD.Les choses que j'ai apprises en cours de route :1) l’injection de dépendances est votre amie.Je ne parle pas d'inversion de conteneurs et de frameworks de contrôle pour assembler des architectures de plugins, mais simplement de transmettre des dépendances au constructeur de l'objet testé.Cela rapporte d'énormes dividendes dans la testabilité de votre code.2) Je suis parti avec la passion/le fanatisme du converti, j'ai saisi un cadre moqueur et j'ai commencé à utiliser des moqueries pour tout ce que je pouvais.Cela a conduit à des tests fragiles qui nécessitaient de nombreuses configurations douloureuses et qui tombaient dès que je commençais une refactorisation.Utilisez le bon type de test double.Des faux où il vous suffit d'honorer une interface, des stubs pour renvoyer des données à l'objet testé, des moqueries uniquement là où vous vous souciez de l'interaction.3) Le test doit être petit.Visez une assertion ou une interaction testée dans chaque test.J'essaie de faire ça et surtout j'y suis.Il s'agit de la robustesse du code de test et également de la complexité d'un test lorsque vous devez le revoir plus tard.

Le plus gros problème que j'ai rencontré avec TDD a été de travailler avec une spécification d'un organisme de normalisation et une implémentation tierce de cette norme qui était de facto la norme.J'ai codé de nombreux tests unitaires vraiment intéressants à la lettre de la spécification pour constater que la mise en œuvre de l'autre côté de la clôture considérait la norme comme davantage un document consultatif.Ils ont joué assez librement avec.La seule façon de résoudre ce problème était de tester l'implémentation ainsi que les tests unitaires et de refactoriser les tests et le code si nécessaire.Le vrai problème était la conviction de ma part que tant que j'avais du code et des tests unitaires, tout allait bien.Ce n’est pas le cas.Vous devez créer des résultats réels et effectuer des tests fonctionnels en même temps que vous effectuez des tests unitaires.De petits avantages tout au long du processus, entre les mains des utilisateurs ou des parties prenantes.

Juste en complément, j'ai pensé dire que j'ai mis un article de blog je fais part de mes réflexions sur le démarrage des tests (suite à cette discussion et à mes propres recherches), car cela peut être utile aux personnes qui consultent ce fil.

"TDD – Premiers pas avec le développement piloté par les tests" - J'ai reçu d'excellents retours jusqu'à présent et j'apprécierais vraiment que vous ayez davantage à nous offrir.

J'espère que ça aide!:)

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top