C'est simple:
By learning to think about the "What" __before__ you think about the "How"
En d'autres termes, penser exactement ce que vous voulez faire (interface), plutôt que de vous comment vous allez le faire (mise en œuvre)
TDD, comme un outil de conception, basé sur mon expérience, vous aide vraiment à voir les choses du point de vue utilisateur que le codeur point de vue. En outre, je pense que TDD permet à votre esprit vraiment pense exactement ce que vous êtes en train de faire, ce qui est le résultat attendu, etc.
Alors la prochaine fois quand vous êtes à essayer de "TDD", demandez-vous ce que c'est que vous essayez de faire, et de commencer à écrire le code qui exprime votre intention.
Exemple:
Dites, quelqu'un veut vous écrire un entier additionneur.
La personne qui ne possède pas de TDD mindest va simplement faire:
int add(int a, int b)
{
return a + b;
}
Est le code ci-dessus est correcte? Assurez-vous qu'il est. Mais cette approche, basée sur mon expérience, échoue lorsque vous avez un complexe de composants à écrire. (C'est pourquoi vous avez posé cette question en premier lieu; je sais, j'avais été là avant de (peut-être encore? lol))
La grande chose au sujet d'ATS est qu'il vous oblige à donner de l'attention d'abord et avant tout de l'interface (ce) du système, tout en ne vous demande pas immédiatement pour la mise en œuvre (le comment).
En d'autres termes, si quelqu'un m'a demandé d'écrire un additionneur, j'aurais quelque chose comme:
void assertOnePlusTwoEqualThree()
{
assert( add(1,2) == 3 );
}
Avis, comment, même avant même de penser à comment l'ajouter() est censé fonctionner, j'ai déjà repassé un peu les choses. C'est, je l'ai déjà trouvé:
- l'interface de mon additionneur à la fois des entrées et des sorties
- la première trivial de cas de test (test unitaire pour libre!!)
ensuite vous mettre en œuvre la méthode add().
Voir, il n'a pas d'importance si la logique discuté ici est si simple à mettre en œuvre. Pour avoir un TDD état d'esprit, est de l'appliquer tout le temps , sans exception. Vous devez le faire autant de fois que vous ne pensez même pas à ce sujet plus. C'est juste une partie de la façon dont vous concevez. Je peux dire cela parce que j'ai vu, il m'est arrivé un professionnel (il a fallu environ un an de persévérance).
De la même manière que si vous le faites toujours un bon travail sur la programmation, quelle que soit la complexité à la main, vous vous approchez de votre travail de la même façon.
Enfin, je pense que le DRT est comparable à un "code d'esquisse." Qui est, vous commencer à essayer pour voir si l'interface fonctionne bien pour chaque scénario (scénario de test). Ainsi il est bon si vous finissez par la modification de l'interface, et les noms, etc. Voir, ce que j'ai appris, c'est que beaucoup de fois, le design est tout simplement de comprendre le problème de fond. ATS est un outil qui vous permet de le faire.
Esprit humain, de l'OMI, des œuvres plus facile avec des exemples concrets (cas de test/scénarios) plutôt que de la pensée abstraite (comment mettre en place quelque chose). En ayant des cas de test, il permet à votre esprit peu à peu apprendre sur le problème que vous essayez de résoudre à la main.
Il est normal de ne pas savoir (pour revenir à la manière "traditionnelle"...détendez-vous, laissez votre esprit d'ajuster). C'est pas grave si c'est pas parfait (l'écriture de certains de la mise en œuvre du code est tout à fait correct...votre cerveau juste essayer de comprendre les choses). Essayez juste de garder, garder la lecture, garder le codage, mais ne jamais abandonner! =)
