J'ai récemment dépensé environ 70% du temps de codage d'un élément d'intégration de fonctionnalités. À un moment donné, je pensais », tout ce travail acharné le teste, je sais que je n'ai pas de bugs ici, pourquoi est-ce que je travaille si fort à ce sujet? Éclaimons simplement sur les tests et terminez-le déjà ... "
cinq minutes plus tard, un test échoue. L'inspection détaillée montre que c'est un bogue important et inconnu dans une bibliothèque tierce que nous utilisons.
Alors ... où attire-tu votre ligne sur quoi tester sur quoi assumer la foi? Testez-vous tout, ou le code où vous attendez la plupart des bugs?
12 Réponses :
Je testez tout. Je déteste ça, mais c'est une partie importante de mon travail.
Je ne peux pas comprendre si vous vouliez écrire «je faisais tester» au passé, ou «je testez tout» au présent.
Désolé pour mon anglais. Je voulais dire «je testez tout», mais alors que Lars A. Brekken a également dit ici, c'est très important de hiérarchiser.
À mon avis, il est important d'être pragmatique lorsqu'il s'agit de tester. Donner la priorité à vos efforts de test sur les choses qui sont les plus susceptibles d'échouer et / ou des choses qu'il est le plus important que cela n'échoue pas (c'est-à-dire une probabilité et une conséquence en considération).
Pensez, au lieu d'aveuglément suite à une métrique telle que la couverture de code.
Arrêtez-vous lorsque vous êtes à l'aise avec la suite de tests et votre code. Revenez et ajoutez plus de tests quand (si?) Les choses commencent à échouer.
+1 pour RiskedbasedSetting (choses qu'il est le plus important que cela n'échoue pas)
Si vous ou votre équipe suiviez des métriques, vous pouvez voir combien de bogues sont trouvés pour chaque test que le cycle de vie logiciel progresse. Si vous avez défini un seuil acceptable où le test de test ne justifie pas le nombre de bugs trouvés, c'est le point à laquelle vous devriez vous arrêter.
Vous ne trouverez probablement jamais 100% de vos bugs.
Vous devriez changer "probablement" à "jamais".
Vous ne pouvez jamais dire qu'un logiciel est sans défaut. L'absence de preuve n'est pas une preuve d'absence.
Public statique Void Main (String [] args) {System.Oout.Print ("Bonjour World!"); } C'est pour des choses muettes comme ces programmes simples que je garde probablement là-bas. Jamais toujours inclus.
Je passe beaucoup de temps sur des tests unitaires, mais très peu de tests d'intégration. Les tests unitaires me permettent de créer une fonctionnalité de manière à structure. Et maintenant, vous avez de jolis tests de documentation et de régression pouvant être exécutés chaque construction
Les tests d'intégration sont une question différente. Ils sont difficiles à maintenir et par définition intègrent de nombreuses fonctionnalités différentes, souvent avec des infrastructures difficiles à utiliser.
bonne question!
Tout d'abord - cela ressemble à vos tests d'intégration étendus payés :)
de mon expérience personnelle:
Combien suffit-il? Question difficile - je ne pense pas qu'il y ait jamais assez!
Je pense que la vraie question est "quand les tests ne deviennent plus bon sens?", En tant que programmeurs, nous pouvons certainement penser que "il ne peut jamais y avoir assez de couverture" (et je suis d'accord dans une mesure), mais certainement mon patron et mon client demanderait à différer.
Accepté-il toujours un bon équilibre. Quantifier la valeur de la couverture de tests étendus aux intervenants non développeurs est un défi. Quelqu'un a de bonnes idées sur la façon de faire ça?
"Trop de tout est juste assez."
Je ne suis pas des pratiques strictes TDD. J'essaie d'écrire suffisamment de tests d'unités pour couvrir tous les chemins de code et exercer tout cas de bord, je pense être important. Fondamentalement, j'essaie d'anticiper ce qui pourrait mal tourner. J'essaie également de faire correspondre la quantité de code de test que j'écris à la façon fragile ou importante, je pense que le code sous test est.
Je suis strict dans une zone: Si un bogue est trouvé, j'ai d'abord rédiger un test qui exerce le bogue et échoue, apportez le code change et vérifie que le test passe.
+1 On écrit un test avant de corriger un bug.
Comme pour tout dans la vie, il est limité par le temps et les ressources et par rapport à son importance. Idéalement, vous testez tout ce que vous pensez raisonnablement pourrait casser. Bien sûr, vous pouvez vous tromper dans votre estimation, mais la plus dépassant de manière à vous assurer que vos hypothèses dépendent de la manière dont un bug important serait contre la nécessité de passer à la section suivante / libération / projet.
Remarque: ma réponse concerne principalement les tests d'intégration. TDD est très différent. Il était couvert de manière à ce que cela auparavant, et vous arrêtez de tester lorsque vous n'avez plus de fonctionnalité à ajouter. TDD concerne la conception, pas la découverte de bugs.
Lorsque vous n'avez plus peur de faire des changements multimédias à majeurs dans votre code, vous avez des chances que vous ayez suffisamment de tests.
J'ai travaillé à QA pendant 1,5 ans avant de devenir développeur.
Vous ne pouvez jamais tout tester (on m'a dit lors de la formation de toutes les permutations d'une seule zone de texte prendrait plus de temps que l'univers connu).
En tant que développeur, ce n'est pas votre responsabilité Test est un exercice de réduction des risques et le client / utilisateur saura ce qui est important et ce qui n'est pas. L'utilisation d'un test d'essai premier à partir d'une programmation extrême sera utile, vous disposez donc d'une bonne base de test et de régler un test de régression après un changement.
Il est important de noter que le code de sélection naturel peut devenir "immunitaire" aux tests. Code complet dit lors de la correction d'un défaut pour écrire un étui à essai et recherchez des défauts similaires, c'est aussi une bonne idée d'écrire un cas de test pour les défauts similaires.
En disant que ce n'est pas votre responsabilité juste parce que vous n'êtes pas à QA s'échappe. Là où je travaille, nous sommes tous des propriétaires de fonctionnalités - nous sommes responsables de conduire nos fonctionnalités à partir de la spécification à concevoir à la mise en œuvre via des tests et de leur déploiement. Vous pouvez utiliser l'aide d'autres personnes, mais c'est votre responsabilité!
Je ne pense pas que j'ai assez clair avec ce que je voulais dire. C'est certainement la responsabilité d'un développeur d'assurer la qualité de leur travail et du produit en cours de construction, de quoi leur responsabilité est-elle de faire appel à des priorités des fonctionnalités s'ils n'ont pas été donnés.
Je préfère le test unit autant que possible. L'un des plus grands effets secondaires (autre que d'augmenter la qualité de votre code et de garder quelques insectes) est que, à mon avis, les attentes de tests d'unité élevées Mes cours sont plus cohérents, plus faciles à lire, et beaucoup plus flexibles car ils sont conçus pour être fonctionnels Cela dit, je suis conforme aux exigences de la couverture de l'unité d'unité de 90% (ligne et branche) utilisant Junit et Cobertura (pour Java). Lorsque je pense que ces exigences ne peuvent pas être satisfaites en raison de la nature d'une classe spécifique (ou de bugs en coobertura), je fais des exceptions.
Les tests unitaires commencent par une couverture et fonctionnent vraiment pour vous lorsque vous les avez utilisés pour tester de manière réaliste les conditions limitrophes. Pour obtenir des conseils sur la manière de mettre en œuvre cet objectif, les autres réponses ont toutes raison.
Cet article donne des idées très intéressantes sur l'efficacité des tests d'utilisateurs avec différents Nombre d'utilisateurs. Il suggère de trouver environ les deux tiers de vos erreurs avec seulement trois utilisateurs testant l'application et jusqu'à 85% de vos erreurs avec seulement cinq utilisateurs.
Le test unitaire est plus difficile de mettre une valeur discrète sur. Une suggestion à garder à l'esprit est que le test unitaire peut aider à organiser vos réflexions sur la manière de développer le code que vous testez. Une fois que vous avez écrit les exigences d'un morceau de code et que vous avez un moyen de vérifier de manière fiable, vous pouvez l'écrire plus rapidement et de manière fiable.
livre classique de Gerald Weinberg " La psychologie de la programmation informatique" a beaucoup de bonnes histoires sur les tests. Un sur moi particulièrement est dans le chapitre 4 " Programmation en tant qu'activité sociale "" Bill "demande à un collègue de revoir son code et de trouver dix-sept bogues dans seulement treize déclarations. Les critiques de code offrent des yeux supplémentaires pour aider à trouver des bogues, plus vous utilisez les yeux plus courants que vous avez de trouver des bugs toujours subtils. Comme Linus a dit: "Compte tenu de suffisamment de globes oculaires, tous les bugs sont peu profonds" tes tests sont des yeux robotiques essentiellement des yeux robotiques qui rechercheront votre code autant de fois que vous le souhaitez à une heure de jour ou de nuit et vous permettrons de savoir si tout est toujours casher. < / p>
Combien de tests suffisent dépend de la question de savoir si vous développez à partir de zéro ou de maintenir un système existant.
Lorsque vous commencez à partir de zéro, vous ne voulez pas passer tout votre temps à rédiger un test et que vous ne suiviez pas de livrer, car les 10% des fonctionnalités que vous avez capables de coder sont testées de manière exhaustive. Il y aura une certaine priorisation à faire. Un exemple est des méthodes privées. Étant donné que les méthodes privées doivent être utilisées par le code visible sous une forme de méthodes privées (publiques / packages / protégées) peuvent être considérées comme couvertes dans les tests pour les méthodes plus visibles. C'est là que vous devez inclure des tests en boîte blanche s'il existe des comportements importants ou obscurs ou des cas de bord dans le code privé.
Les tests devraient vous aider à vous assurer que vous devez vous assurer que 1) comprendre les exigences, 2) adhérer à de bonnes pratiques de conception en codant pour la qualification, et 3) savoir quand le code existant cesse de fonctionner. Si vous ne pouvez pas décrire un test pour une fonctionnalité, je serais disposé à parier que vous ne comprenez pas la fonctionnalité suffisamment bien pour la coder proprement. L'utilisation de l'unité de test de test vous oblige à faire des choses comme transmettre comme argument ces éléments importants tels que les connexions de base de données ou les usines d'instances au lieu de donner à la tentation de la maîtrise de la classe de faire trop de choses et de devenir un objet «dieu». Laisser votre code soit votre canari signifie que vous êtes libre d'écrire plus de code. Lorsqu'un test précédemment passant échoue, cela signifie que l'une des deux choses, soit le code ne fait plus ce que l'on attendait ou que les exigences de la fonctionnalité ont changé et que le test doit simplement être mis à jour pour répondre aux nouvelles exigences.
Lorsque vous travaillez avec le code existant, vous devriez pouvoir montrer que tous les scénarios connus sont couverts de manière à ce que lorsque la prochaine demande de modification ou correction de bugs se présente, vous serez libre de creuser dans n'importe quel module que vous voyez. S'inquiéter, "Et si je casse quelque chose", ce qui conduit à dépenser plus de temps tester des tests de petite taille, alors il a fallu pour changer le code.
Ainsi, nous ne pouvons donc pas vous donner un nombre difficile et rapide de tests, mais vous devez tirer un niveau de couverture qui augmente votre confiance dans votre capacité à continuer à modifier ou à ajouter des fonctionnalités, sinon vous avez probablement atteint le point de rendements diminués.