Le truc que j'ai découvert à propos du TDD, c'est qu'il faut du temps pour mettre en place ses tests et, étant naturellement paresseux, je veux toujours écrire le moins de code possible. La première chose que je semble faire est de tester que mon constructeur a défini toutes les propriétés, mais est-ce excessif ?
Ma question est de savoir à quel niveau de granularité vous écrivez vos tests unitaires ?
et y a-t-il un cas où l'on teste trop ?
Je suis payé pour un code qui fonctionne, pas pour des tests, et ma philosophie consiste donc à tester le moins possible pour atteindre un niveau de confiance donné (je soupçonne que ce niveau de confiance est élevé par rapport aux normes de l'industrie, mais cela pourrait n'être que de l'orgueil). Si je ne fais pas typiquement un type d'erreur (comme définir les mauvaises variables dans un constructeur), je ne le teste pas. J'ai tendance à donner un sens aux erreurs de test, donc je fais très attention lorsque j'ai une logique avec des conditionnels compliqués. Lorsque je codifie en équipe, je modifie ma stratégie pour tester soigneusement le code que nous avons tendance, collectivement, à mal faire.
Différentes personnes auront des stratégies de test différentes basées sur cette philosophie, mais cela me semble raisonnable étant donné l'état immature de la compréhension de la façon dont les tests peuvent s'intégrer au mieux dans la boucle interne du codage. Dans dix ou vingt ans, nous aurons probablement une théorie plus universelle sur les tests à écrire, ceux à ne pas écrire et comment faire la différence. En attendant, l'expérimentation semble de mise.
Écrivez des tests unitaires pour les choses que vous vous attendez à casser, et pour les cas limites. Ensuite, les tests doivent être ajoutés au fur et à mesure que les rapports de bogues arrivent - avant d'écrire le correctif pour le bogue. Le développeur peut alors être sûr que :
Dans le commentaire ci-joint, je pense que cette approche de l'écriture des tests unitaires pourrait poser des problèmes si de nombreux bogues sont découverts au fil du temps dans une classe donnée. C'est probablement là que la discrétion est utile - ajouter des tests unitaires uniquement pour les bogues qui sont susceptibles de se reproduire, ou pour lesquels leur réapparition causerait de sérieux problèmes. J'ai trouvé qu'une mesure de test d'intégration dans les tests unitaires peut être utile dans ces scénarios - tester le code en haut des chemins de code peut couvrir les chemins de code en bas.
Tout doit être rendu aussi simple que possible, mais pas plus simple. - A. Einstein
L'une des choses les plus mal comprises à propos de TDD est le premier mot qui le compose. Test. C'est pourquoi BDD est apparu. Parce que les gens ne comprenaient pas vraiment que le premier D était le plus important, à savoir Driven. Nous avons tous tendance à penser un peu trop aux tests, et un peu trop peu à la conduite de la conception. Et je suppose que c'est une réponse vague à votre question, mais vous devriez probablement considérer comment piloter votre code, plutôt que ce que vous testez réellement ; c'est quelque chose pour lequel un outil de couverture peut vous aider. La conception est une question bien plus importante et plus problématique.
À ceux qui proposent de tester "tout" : réaliser que "tester complètement" une méthode comme int square(int x) nécessite environ 4 milliards de cas de test dans des langages courants et des environnements typiques.
En fait, c'est même pire que cela : une méthode void setX(int newX) est également tenu pas pour modifier les valeurs de tout autre membre que x -- est-ce que tu testes que obj.y , obj.z etc. restent inchangés après avoir appelé obj.setX(42); ?
Il est seulement pratique de tester un sous-ensemble de "tout". Une fois que vous acceptez cela, il devient plus acceptable d'envisager de ne pas tester un comportement incroyablement basique. Chaque programmeur a un distribution des probabilités de l'emplacement des bogues ; l'approche intelligente consiste à concentrer votre énergie sur les régions de test où vous estimez que la probabilité de bogue est élevée.
La réponse classique est "testez tout ce qui pourrait être cassé". J'interprète cela comme signifiant que tester les setters et getters qui ne font rien d'autre que set ou get est probablement trop de tests, pas besoin de prendre le temps. A moins que votre IDE ne les écrive pour vous, alors vous pourriez aussi bien le faire.
Si votre constructeur pas Si la définition des propriétés peut entraîner des erreurs par la suite, il n'est pas inutile de vérifier qu'elles sont définies.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
