Nous sommes dans la phase initiale d'essayer de mettre en œuvre TDD. Je démo'd la couverture de code système de l'équipe Visual Studio Team / TDD et l'équipe est excitée aux possibilités. Actuellement, nous utilisons DevPartner pour la couverture de code, mais nous voulons l'éliminer parce que c'est cher. Nous avons une expérience très limitée dans TDD et nous voulons nous assurer que nous n'allons pas une mauvaise direction. Actuellement, nous utilisons SourceSafe pour le contrôle de la source mais migreront vers le système d'équipe dans environ un an.
Je peux vous dire que nos applications sont des données très centrées. Nous avons environ 900 tables, 6000 procédures stockées et environ 45 Go de données. Nous avons beaucoup de calculs basés sur UserData et différents tarifs dans le système. De plus, beaucoup de notre code repose sur le temps (calculez l'intérêt à la date actuelle). Certains de ces calculs sont très complexes et très intensives (seulement quelques personnes connaissent les détails de certains d'entre eux).
Nous voulons mettre en œuvre TDD pour résoudre des problèmes d'assurance qualité. Beaucoup de développeurs sont obligés de réparer des bugs dans les zones qu'ils ne connaissent pas et finissent par casser quelque chose. Il existe également des zones que les développeurs ont presque peur de toucher car le code est utilisé par tout dans le système. Nous voulons atténuer ce problème.
J'ai bien peur, car notre code est si centralisé que la mise en œuvre de TDD pourrait être un peu plus complexe que la plupart des systèmes. J'essaie de trouver un plan de jeu que je peux présenter à la direction, mais je veux, espérons-le, ne vous êtes pas rattrapé dans certaines des erreurs de débutant TDD. De plus, si des outils / installations du système d'équipe rendent TDD plus complète, ce serait bien, mais nous ne voulons pas attendre que le système d'équipe commence à démarrer.
La première question que nous avons demandée est de commencer simplement avec les outils dans Visual Studio? J'ai lu après que les gens se plaignent des outils intrinsèques dans Visual Studio ( besoin de créer un projet séparé pour créer votre test ) mais la seule chose à propos des outils de Visual Studio est qu'elles sont libres et l'intégration est bon. Si nous décidons d'aller à l'aide de quelque chose comme Xunit, Mbunit ou Nunit, nous aurons probablement un coût aussi significatif:
1) Si nous voulons que l'intégration des IDE (n'a pas mentionné la majeure partie de notre code est VB.NET) 2) Si nous voulons une couverture de code Aussi j'ai vu une certaine fonctionnalité assez cool démoée dans Visual Studio 2010. Comme la possibilité de faire des tests d'entrée (données saisies sur un formulaire) ou la possibilité d'enregistrer ce que l'utilisateur a fait, puis de l'alimenter dans votre test de l'appareil. reproduire un problème.
Aussi, bien que je ne saisis pas encore le concept d'objet moqueur, je sais que beaucoup de gens estiment que c'est un must. La question est que tous les cadres moqueurs peuvent-ils brancher la version de TDD (MSSTest) de Visual Studio?
J'ai conseillé de la direction que nous devrions probablement simplement ajouter des tests de régression à l'avenir (nouveau développement ou bogues trouvés), mais n'essayez pas de passer par notre code et de mettre des tests d'unité. Ce serait beaucoup trop grand de projet.
Quoi qu'il en soit, j'apprécierais l'aide de Tayone.
---Testdriven.net ou Resharper ou ?????
--- NCOVER (semble assez cher pour sa fonctionnalité)
7 Réponses :
La première chose à faire est d'obtenir ce livre:
Travailler efficacement avec le code hérité
Pour un tel projet, lisez-le et intériorisez-le. TDD sur une application axée sur les données est assez difficile. Sur un héritage, vous avez besoin d'une planification et d'un effort sérieux. La peine à mon avis, mais c'est toujours une grande courbe.
Je recommanderais également le livre de Roy Osherove sur les tests unitaires. Je ne suis pas convaincu que TDD est le moyen de faire un projet comme celui-ci. C'est un peu comme fermer la porte de la grange après que les vaches rentrent chez elles.
1) J'utilise Testdriven.net, et je l'aime aussi un +1 de moi pour ça Je n'ai utilisé que NCOver, je ne peux donc pas vous recommander des alternatives.
En ce qui concerne la moqueur - une fois que vous saisissez ce dont il s'agit et ce que cela signifie vraiment pour vous, vous verrez les avantages qu'il a à offrir. À savoir, cela signifie que vous n'êtes pas dépendant de l'intégration du code que vous testez avec une dépendance extérieure et permet également de conserver le temps d'exécution du texte (par exemple, la moqueur de votre couche d'accès aux données empêche l'interaction coûteuse avec la DB). C'est un facteur important à mon avis que si les tests prennent beaucoup de temps à courir, les gens peuvent commencer à ne pas la déranger de les exploiter si cela signifie qu'ils doivent attendre trop longtemps! J'utilise Nunit, qui prend en charge des simulacres intégrés.
Attachez une approche TDD dans un environnement d'intégration continue (par exemple Cruisecontrol.net ), et vous avez une configuration très puissante et productive.
Lors du démarrage des tests TDD / unité, je recommande toujours à écrire des tests pour le code écrit à partir « maintenant » partir et ne se concentre pas trop sur l'écriture de tests pour le code héritage / existant. C'est beaucoup plus difficile à faire en général et beaucoup plus cher du temps, en particulier si le code est vieux / pas frais chez quelqu'un!
Lorsque vous essayez de vous lever et de courir avec TDD / des tests unitaires et de gagner de l'élan avec toute l'équipe, vous voulez que cela soit aussi positif et productif que possible. Les tests d'écriture pour le code ancien qui ne sont pas changés au cours de cette période initiale est coûteux par rapport au nouveau code, car le code n'est pas frais, la complexité exacte de celui-ci doit plus que probablement être élaborée à nouveau et pas nécessairement par le programmateur d'origine. De plus, le fait que vous puissiez bien avoir du mal à justifier à l'entreprise, le temps nécessaire pour passer à la révision de l'ancien code pour écrire des tests pour eux, au lieu de travailler sur de nouvelles fonctionnalités / correction de bugs / problèmes réels.
Cela peut devenir une expérience négative - un développeur qui est chargé de rédiger les tests d'un code ancien qu'il connaît / se souvient peu de choses sur le point de trouver plus difficile à faire et donc leur première expérience n'est pas positive. Vous devez également faire attention dans cette situation, car vous pouvez vous retrouver avec des tests faibles qui vous donne une fausse confiance. Dans mon expérience, il est absolument essentiel que tout le monde sort à un début positif avec cela, sinon la confiance / la motivation de celui-ci s'estompe et le résultat final est bien pire.
Je suis pas dire que vous ne devriez pas ajouter de tests pour le code hérité - je fais moi-même quand je travaille dans ou autour du code plus ancien qui n'a pas de test pour être bit-by- Bit, améliorer la couverture de test et la qualité. La différence est que je suis déjà à bord avec le processus, un "croyant". C'est les premières étapes de celui-ci, qui sont la clé ... D'où mon point de ne pas vous concentrer trop sur le code hérité au début.
2) La couverture de code est utile, lorsqu'elle pensait dans le bon état d'esprit:
La couverture de code élevé ne signifie pas nécessairement des tests d'unités de haute qualité, mais ...
Des tests d'unités de haute qualité signifie une couverture de code haute de haute qualité
Votre commentaire à propos de Pas unitaire Test Le code hérité est absolument en arrière. Vous devez établir une bonne série de tests unitaires sur la base de code héritée afin que vous puissiez refactuer en toute sécurité, sans vous soucier de casser quelque chose.
@Robert - Je ne pense pas que c'est à l'envers du tout. J'ai clarifié mon opinion ci-dessus.
Eh bien, j'aimerais commencer par recommander que vous apportiez une société de conseil qui connaît TDD pour aider votre équipe à démarrer. Ceci est particulièrement important si vous n'avez aucune personne de l'équipe qui connaît le TDD, les tests unitaires, les cadres moqueurs, etc. Je ne sais pas combien d'achat vous avez déjà de la direction ou de l'équipe, mais vous n'avez pas t Vous voulez que votre première tentative échoue, à cause des erreurs qui auraient pu être empêchées d'embaucher un spécialiste de vous aider à prendre ces premières étapes.
Quoi qu'il en soit, je vous recommanderais de commencer petit et choisissez un nouveau projet qui n'est pas extrêmement grand. Même un petit sous-ensemble d'un projet plus vaste fonctionnerait. Utilisez-le à la fois comme un endroit pour faire connaître l'équipe avec TDD et montrer la gestion qu'elle est réalisable. Ensuite, une fois que l'équipe est plus versée, vous pouvez choisir à des projets plus importants. En ce qui concerne le code hérité, je recommanderais de regarder ce livre:
Travailler efficacement avec le code hérité, Michael Plumes
aussi je recommanderais sûrement de jeter un coup d'œil à ce livre:
Art des tests unitaires, Roy Osherove
Ce n'est peut-être pas un livre TDD, mais c'est un excellent livre pour en savoir plus sur les tests unitaires, les cadres moqueurs, et il a même un chapitre sur le code hérité. De plus, il a des recommandations sur la manière d'acheter de l'équipe et de la gestion. Cela parle un peu à propos de TDD, des tests d'intégration, de l'organisation de votre codeBase et de manière approfondie de ce qui fait un bon test unitaire. Tous dans une grande lecture.
J'espère que cela aide.
100 pouces pour travailler efficacement avec le code hérité recommandé par Yishai. Je recommande également Test de l'unité pragmatique en C # avec Nunit comme vous utilisez .net (bien que je suppose que c #). Il a été très utile d'enseigner les bases des tests unitaires, en fournissant une base solide au travail.
Ne vous précipitez pas et pour l'amour de Dieu, n'essayez pas de forcer les développeurs à faire TDD.
Sinon, vous obtiendrez des «tests» en désordre, qui seront supprimés après quelques mois et des développeurs qui ne voudront plus jamais entendre parler de TDD.
Exigence la plus importante pour TDD - bonne connaissance de savoir comment écrire des tests (assez évident pourquoi).
deuxième exigence - bon Connaissance des technologies d'occasion. Les outils d'occasion sont effectivement sans importance.
P.s. tonnes de code hérité et application centrée sur les données => un bon moule pour désastre.
C'est parce qu'il est difficile de coder quoi que ce soit, la conception du code dans la tête sera impossible.
Pendant quelques années, j'étais au courant des tests d'unité d'écriture. Ce qui m'a permis d'engager vraiment des tests unitaires lorsque j'ai commencé à travailler sur un projet open source avec une couverture de test impressionnante. Cela m'a vraiment frappé que la façon dont j'écris un logiciel était "du mauvais côté de l'histoire".
Vous avez mentionné de nombreux outils dont les capacités annoncées vous excitent et vous demandaient comment les mettre ensemble. Je pense que ces questions sont très bien abordées par "Xunit Test Sticks", de Addison-Wesley ( http://xunitpatterns.com/ < / a>). Ce livre m'a permis de rassembler tous ces outils et techniques que je lisais dans le passé.
Le livre peut mieux servir un public qui apprécie également d'autres livres comme la gang de quatre modèles de conception, refactoring et refactorisant les modèles. Ces livres sont également géniaux, bien qu'ils n'auraient pas eu de changement de changement de la façon dont j'ai codé après que je les ai lu. La présentation des modèles de test Xunit reflète cependant le style des livres. Ils peuvent être difficiles à lire au début, car ils ont tendance à transversalement les chapitres de référence dans les directions arbitraires. Je pense qu'ils sont très solides cependant.
Le GOF a présenté des catégories de motifs - créationnelles, structurelles et comportementales. Ces catégories servent de moyen d'associer et de contraster les motifs expliqués. En associant des modèles de conception de test avec la durée de vie typique d'un test d'unité, les modèles de test Xunit tissent également une gamme de techniques disponibles pour les tests unitaires. Les mêmes étapes sont également utilisées pour associer et contraster divers outils utilisés pour les tests d'unités de construction.
Cela aidera à la vue de haut niveau et passera à la mise en œuvre effective.
Ma seule critique des modèles de test Xunit est la quantité de texte qu'ils utilisent pour critiquer Nunit. Nunit est un bon point de programmation, à son auditeur de l'auteur que nous nous avons mentionné si en évidence dans ce que je pense devenir un livre classique.
En ce qui concerne la mise en route, je vous recommanderais également de lire Fowler's Refactoring . Le premier chapitre donne une bonne idée de ce que cela signifie d'introduire des tests, puis d'introduire en toute sécurité les modifications (bien que l'accent est mis sur le comportement préservant le changement). De plus, Cette Talk décrit certaines pratiques qui peuvent aider à améliorer la testabilité de votre code. Misko Heusvery a aussi Ce Guide de la rédaction de code testable, qui résume la conversation. < / p>
Dans votre description, il semble que vous souhaitiez tester les parties principales de votre système - les pièces avec beaucoup de dépendances lorsque des changements sont effrayants. Selon le degré d'accès des données découplé de la logique commerciale, vous devrez probablement refroidir vers un état où le code est plus testable - où il est facile et rapide d'instancier les ensembles de données de test afin de vérifier la logique de manière isolée. . Cela peut être un gros travail et peut ne pas valoir l'effort si les changements ici sont peu fréquents et que la base de code est bien prouvée.
Mon conseil serait d'être pragmatique et d'utiliser l'expérience de l'équipe pour trouver des zones où il est plus facile d'ajouter des tests qui ajoutent de la valeur. Je pense que de nombreux tests unitaires ciblés est le meilleur moyen de conduire la qualité, mais il est probablement plus facile de tester le code à un niveau supérieur à l'aide de tests d'intégration ou de scénario, certainement au début. De cette façon, vous pouvez détecter de gros échecs dans vos systèmes de base tôt. Soyez clair sur ce que vos tests couvrent. Les tests de scénario couvriront beaucoup de code, mais ne vont probablement pas surfer sur des bugs subtils.
Déplacement de SourceSafe au système d'équipe est une étape importante, quelle taille dépend de combien vous voulez faire dans le système d'équipe. Je pense que vous pouvez obtenir beaucoup de valeur d'utiliser le cadre de test intégré de Visual Studio. Par exemple, comme une première étape, vous pouvez implémenter des suites de test de base pour les cas d'utilisation du système central / de noyau. Les développeurs peuvent s'exécuter eux-mêmes dans Visual Studio lorsqu'ils travaillent et avant d'arriver à l'enregistrement. Ces suites peuvent être élargies progressivement au fil du temps. Plus tard, lorsque vous obtenez TFS, vous pouvez rechercher ces suites lors de l'enregistrement et dans le cadre d'un processus de construction automatisé. Vous pouvez suivre un chemin similaire quel que soit les outils spécifiques.
Soyez clair dès le départ qu'il existe des frais généraux dans le maintien du code de test et que vous avez des tests bien conçus, vous pouvez payer des dividendes. J'ai vu des situations où les tests sont collés, puis modification de code de test comme ceci peut conduire à une explosion dans le nombre de lignes de code de test que vous devez maintenir lors d'un changement de code de petit produit. Ce type de tracas peut éroder le bénéfice perçu d'avoir les tests.
Visual Studio 2008 ne vous montrera que la couverture des blocs, bien que l'analyse de code donnera également d'autres métriques telles que la complexité cyclomatique par montage / classe / méthode. Obtenir une couverture de blocs élevée avec vos tests est certainement importante et vous permet d'identifier facilement les zones du système totalement non testées.
Cependant, je pense qu'il est important de se rappeler que la couverture de blocs élevée n'est qu'une simple mesure de l'efficacité de vos tests. Par exemple, disons que vous écrivez une classe pour purger une archive de fichier et conserver les 5 derniers fichiers. Ensuite, vous écrivez un cas de test qui vérifie si vous commencez avec 10 fichiers, puis exécutez la purger que vous restiez avec 5. Une implémentation qui passe le test pourrait supprimer les fichiers les plus récents, mais pourrait facilement donner une couverture à 100%. Ce test ne vérifie que 1 des exigences.
TDD! = Test unitaire. Déposez la balise TDD - appelez simplement le test.