TDD, Quelles sont vos techniques pour trouver de bons tests?

Question

Je suis en train d’écrire une application web simple en utilisant Linq to Sql comme ma couche de données car j’aime beaucoup Linq2Sql. Je lisais un peu sur DDD et TDD ces derniers temps et je voulais tenter ma chance.

Tout d’abord, il me semble que Linq2Sql et DDD ne vont pas très bien. Mon autre problème est de trouver des tests. En fait, je trouve très difficile de définir les bons tests. Je voulais donc vous demander quelles sont vos meilleures techniques pour découvrir de bons tests.

Answer 1

La découverte de scénarios de test est plus un art qu'une science. Cependant, les directives simples incluent:

• Code que vous savez fragile / faible / susceptible de se briser
• Suivez le scénario de l'utilisateur (ce que votre utilisateur va faire) et voyez comment il va toucher votre code (cela signifie souvent le débogage, le profilage et d'autres fois, une réflexion sur le scénario) - quels que soient les points de votre le code a été touché par l'utilisateur, ce sont la priorité la plus élevée pour écrire des tests.
• Au cours de votre propre développement, les tests que vous avez exécutés ont abouti aux bogues que vous avez trouvés - écrivez des tests pour éviter que le code ne régresse à nouveau avec le même comportement.

Il existe plusieurs ouvrages sur la rédaction de scénarios de test, mais si vous travaillez dans une grande entreprise nécessitant des scénarios de test documentés, le mieux est de penser à toutes les parties de votre code que vous n'aimez pas. (qui ne sont pas "purs") et assurez-vous de pouvoir tester ces modules de manière approfondie.

Answer 2

Eh bien, selon l’interprétation standard de TDD, les tests pilotent votre développement. Donc, en gros, vous commencez par le test. Cela échouera et vous écrirez du code jusqu'à ce que le test réussisse. Donc, cela dépend en quelque sorte de vos besoins, peu importe la façon dont vous les collectez. Vous décidez ce que votre application / fonctionnalité doit faire, écrivez le test, puis codez jusqu'à ce qu'il passe. Bien sûr, il existe de nombreuses autres techniques, mais il ne s'agit que d'un bref énoncé de ce que l'on pense généralement dans le monde du TDD.

Answer 3

Pensez . Lire le code. Interrogez vous-même: par exemple ce pointeur ne peut-il jamais être NULL ici? Que se passe-t-il si cette méthode est appelée avant l'initialisation?

Ne faites pas de suppositions telles que " ce fichier sera toujours présent ". Tester.

Pensez aux cas extrêmes, aux limites, aux valeurs négatives, aux débordements ...

Les bogues sont souvent regroupés par cluster. Regardez autour de vous quand vous en trouvez un. Recherchez également le même type de bogue à d’autres endroits.

Answer 4

Déterminez l'objectif réel de tester: trouver des bogues.

Faites preuve d'imagination pour imaginer ce qui pourrait faire échouer votre programme.

Vos tests doivent rechercher des bogues et non confirmer que votre programme fonctionne correctement.

Answer 5

J'écris régulièrement des tests pour les API tierces. Ainsi, lorsque l’API se mettra à jour, je saurai si je vais faire une pause ou non.

Answer 6

Je pense que c'est une technique utile:

Utilisation de contrats et de requêtes booléennes pour améliorer la qualité de la génération de tests automatiques

Référence: Lisa (Ling) Liu, Bertrand Meyer et Bernd Schoeller, Utilisation de contrats et de requêtes booléennes pour améliorer la qualité de la génération automatique de tests , dans les procédures de TAP: Tests Et preuves , ETH Zurich, 5-6 février 2007, eds. Yuri Gurevich et Bertrand Meyer, Notes de cours en informatique, Springer- Verlag, 2007.