Qu'est-ce qu'un test d'unité?

Je suis Java maintenant, avant que ce C ++, avant que C. Je suis tout à fait convaincu que chaque œuvre que j'ai faite, que je suis maintenant immuable, a été renforcée par les stratégies de test que j'ai choisies. Ébrécher les tests mals.

Je suis sûr que vous testez le code que vous écrivez. Quelles techniques utilisez-vous? Par exemple, vous pourriez vous asseoir dans un débogueur et passer à travers le code et regarder ce qui se passe. Vous pourriez exécuter le code contre certaines données de test que quelqu'un vous a donné. Vous pouvez concevoir des entrées particulières car vous savez que votre code a des comportements intéressants pour certaines valeurs d'entrée. Supposons que vos affaires utilisent les choses de quelqu'un d'autre et que ce n'est pas encore prêt, vous vous moquez de leur code afin que votre code puisse fonctionner avec au moins certaines fausses réponses

Dans tous les cas, vous pourriez être dans une certaine mesure unitaire. Le dernier est particulièrement intéressant - vous testez beaucoup de manière isolée, testez votre unité, même si le leur n'est pas encore prêt.

Mon avis:

1). Les tests qui peuvent facilement être rénovés sont très utiles - capturer sans fin des défauts de rampants tardifs. En cas de contraste assis dans un débogueur, il y a un engourdissement.

2). L'activité consistant à construire des tests intéressants lorsque vous écrivez votre code ou avant d'écrire votre code, vous vous concentrez sur vos cas de franges. Ces entrées gênantes zéro et nulle, celles "désactivées par une erreur". Je perçoive un meilleur code qui sort à la suite de bons tests unitaires.

3). Il y a un coût de maintien des tests. Généralement, cela en vaut la peine, mais ne sous-estimez pas l'effort de les garder à travailler.

4). Il peut y avoir une tendance à des tests unitaires trop propulsés. Les bugs vraiment intéressants ont tendance que ot fluage lorsque des pièces sont intégrées. Vous remplacez cette bibliothèque que vous vous moquez avec la vraie chose et lo! Cela ne fait pas tout à fait ce qu'il a dit sur l'étain. Il reste également un rôle pour les tests manuels ou explorateurs. Le testeur humain perspicace trouve des défauts spéciaux.

point par point:

1) Qu'est-ce qu'un test d'unité?

Un test unitaire est un test logiciel conçu pour tester une unité distincte de fonctionnalité de logiciels.

2) Je comprends que, essentiellement, vous essayez d'isoler la fonctionnalité atomique, mais comment testez-vous cela?

Les tests unitaires sont en réalité un bon moyen d'appliquer certains principes de conception; L'un des aspects d'entre eux est qu'ils font réellement un effet subtil mais significatif sur la conception du code. La conception de test est une chose importante; Être capable de tester (ou non) un certain nombre de code peut être très important; Lorsque des tests d'unités sont utilisés, les conceptions ont tendance à migrer vers le côté "plus atomique" du spectre.

3) Quand est-ce nécessaire?

Il y a beaucoup d'opinions variables sur celui-ci. Certains disent que c'est toujours nécessaire, certains disent que c'est complètement inutile. J'aurais affirmé que la plupart des développeurs expérimentés avec des tests unitaires diraient que des tests d'unités sont nécessaires à tout code de chemin critique qui a une conception pouvant être conçue pour tester un appareil (je sais que c'est un peu circulaire, mais voir n ° 2 ci-dessus). < / p>

4. Quand est-ce ridicule? Pouvez-vous donner un exemple?

   En règle générale, l'autre est l'endroit où vous entrez dans la fin ridicule du spectre. Par exemple, si vous avez une classe de vecteur 3D contenant des accesseurs pour chacun des composants scalaires, les tests unitaires pour chacun des accessoires scalaires confirmant la gamme complète d'entrées et vérifiant que les valeurs de chacune d'elles seraient considérées comme un peu de surkill par certains. D'autre part, il est important de noter que même ces situations peuvent être utiles à tester.

   5. Je l'entends surtout de Java Devs sur ce site, alors peut-être que cela est spécifique aux langues orientées objet?

      Non, c'est vraiment applicable à tout logiciel. La méthodologie de test de l'unité est arrivée à la maturité avec un environnement Java, mais elle est vraiment applicable à une langue ou à une autre environnement.

      6. Qu'est-ce que c'est tout?

         Le test unitaire est, à un niveau très basique, tout sur la vérification et la validation des comportements attendus d'une unité de code sont en réalité ce que le code fait.

La définition la plus simple / non technique que je peux trouver de manière automatisée pour tester des parties du code ...

Je l'utilise et je l'aime ... mais pas religieusement, l'un des Mes moments les plus fiers des tests unitaires étaient un calcul d'intérêt que j'ai fait pour une banque, extrêmement compliqué et que je n'avais qu'un bug et qu'il n'y avait pas de test de l'unité pour ce cas ... Dès que j'ai ajouté le cas et corrigé mon code, était parfait.

prenant cet exemple j'avais un appel de classe INTERNALCALCULATION et qu'il avait des propriétés pour tous les arguments et une seule méthode publique calculer () Là où plusieurs étapes du calcul et si je l'essaie d'essayer d'écrire le tout dans une seule méthode et de vérifier mon résultat, il aurait été accablant d'essayer de trouver où mon bug / s ... alors j'ai pris chaque étape du calcul et créé une méthode privée et un test de l'unité / s pour tous les cas différents. (Certaines personnes vous diront de tester uniquement les méthodes publiques, mais dans ce scénario, il a fonctionné mieux pour moi ...) Un exemple des méthodes privées était la suivante:

Méthode: < / p> xxx

Méthodes de test:

note: je les nommerais différemment maintenant, au lieu de chiffres que je voudrais fondamentalement mettre le résumé dans la Nom de la méthode. xxx

où est-il ridicule?

Eh bien à chacun ... Plus vous le faites, vous trouverez ce que vous trouverez où il est utile et où il semble "être ridicule" mais personnellement, je ne l'utilise pas pour tester ma base de données de la manière dont la plupart des testeurs de l'unité hardcore ... En ce sens que j'ai des scripts pour reconstruire le schéma de base de données , repeuplez la base de données avec des données de test, etc. J'écris habituellement une méthode de test de l'unité pour appeler ma méthode de dataAccess et l'étiqueter avec un suffixe de débogage comme celui-ci: FindLoannots_debug () Et j'ai pu mettre System.Diagnostics.debugger.break () Donc, si je les exécute en mode de débogage, je peux vérifier manuellement mes résultats.