Tout d'abord, il est bon et normal de se sentir frustré quand vous commencez à essayer d'utiliser TDD dans votre style de codage. Il suffit de ne pas se décourager et quitter, vous aurez besoin de donner un peu de temps. C'est un changement de paradigme majeur dans la façon dont nous pensons à propos de la résolution d'un problème dans le code. J'aime penser que c'est comme quand on est passé d'procédurale à la programmation orientée objet.
Deuxièmement, j'ai l'impression que développement piloté par les tests est d'abord et avant tout une activité de conception qui est utilisé pour la chair de la conception d'un composant par la création d'un test qui décrit tout d'abord l'API, il va exposer et comment vous allez consommer de la fonctionnalité. L'aide du test de la forme du moule et le Système Sous Test jusqu'à ce que vous avez été capable d'encapsuler suffisamment de fonctionnalités pour satisfaire quels que soient les tâches que vous arrive de travailler sur.
En prenant le paragraphe ci-dessus à l'esprit, examinons à vos questions:
- Si je suis en utilisant une collection dans mon système sous test, alors je vais l'installation d'une attente, assurez-vous que le code a été appelée pour insérer l'élément puis affirmer le comte de la collection. Je n'ai pas forcément de test de la méthode Add sur ma liste interne. J'ai juste assurez-vous qu'il a été appelée lorsque la méthode qui ajoute l'élément est appelé. - Je le faire en ajoutant un moqueur de cadre dans le mélange, avec mon framework de test.
- Les tests de chaînes de caractères en sortie peut être fastidieux. Vous ne pouvez pas en compte pour chaque résultat. Vous ne pouvez tester ce que vous attendez basé sur les fonctionnalités du système sous test. Vous devriez toujours casser vos tests, jusqu'au plus petit élément que c'est le test. Ce qui signifie que vous aurez beaucoup de tests, mais les tests qui sont petits et rapides et tester ce qu'ils devraient, rien d'autre.
- Il y a beaucoup de open source de test de cadres à choisir. Je ne vais pas argumenter qui est le meilleur. Il suffit de trouver celui que vous aimez et commencer à l'utiliser.
- Tout ce que vous pouvez faire est de configurer votre tests pour tenir compte de ce que vous voulez arriver. Si un scénario vient qui introduit un bug dans votre fonctionnalité, vous aurez au moins un test autour de la fonctionnalité à ajouter que le scénario dans le test et ensuite modifier votre fonctionnalité jusqu'à ce que le test passe. Une façon de trouver l'endroit où nous avons peut-être manqué un test est d'utiliser la couverture de code.
Je vous ai présenté les moqueries terme dans la réponse à la question. Lorsque vous introduisez les moqueries dans votre arsenal pour le TDD, il a considérablement facilite les tests d'abstraction pour les pièces qui ne font pas partie du système sous test. Voici quelques ressources sur le moqueur des cadres il y a:
Une façon de les aider dans l'utilisation de TDD, en plus de la lecture sur les processus, est de regarder les gens faire. Je vous recommande de regarder l'écran jette par JP Boodhoo sur DNRTV. Découvrez ces:
OK, ces va vous aider à voir comment les termes que j'ai présenté sont utilisés. Il présentera également un autre outil appelé Resharper et comment elle peut faciliter le processus TDD. Je ne peux que recommander cet outil assez quand vous faites TDD. Semble que vous soyez, le processus d'apprentissage et que vous êtes juste de trouver certains des problèmes qui ont déjà été résolus avec l'aide d'autres outils.
Je pense que je ferais une injustice à la communauté, si je n'ai pas de mise à jour par l'ajout de Kent Beck nouvelle série sur le Développement Piloté par les tests sur pragmatic programmer.
