Un moyen automatisé pour détecter les tests qui ne peuvent pas échouer, enregistré pour obtenir une couverture minimale du code?

Question

J'ai un développeur qui va contourner notre couverture de code en écrivant des tests qui n'échouent jamais.

Le code est simplement atroce, mais les tests ne le détectent jamais car ils affirment (true).

Je code révision, mais je ne peux pas tout le monde travaille pour eux, tout le temps. Comment incitez-vous des personnes comme celle-ci à créer un bon logiciel?

Existe-t-il un plugin de construction permettant de détecter les tests qui ne peuvent échouer?

C #, tests mbUnit.

Answer 1

La vraie motivation vient de l’intérieur. Certaines personnes vont jouer avec le système chaque fois qu’elles en ont la chance, parfois, sans autre raison qu’elles ne le peuvent. D'autres le font simplement parce qu'ils sont des hackers.

Cela dit, en supposant que vous soyez le responsable, demandez à "venir voir Jésus". rencontre avec le dev. Si cela ne fonctionne toujours pas, il y a toujours la porte.

Si vous n'êtes pas le responsable, choisissez les canaux appropriés.

Answer 2

Je pense que vous avez presque répondu à la question pour vous-même. Si vous avez quelqu'un qui travaille pour vous ou avec vous (vous ne savez pas clairement si vous êtes le responsable de ce développeur), s'il ne le fait pas correctement, il existe sûrement des procédures permettant d'indiquer clairement à cette personne qu'elle ne produisent pas un travail de qualité acceptable.

Le développeur est-il nouveau sur TDD? Peut-être qu’ils ont besoin de savoir comment écrire de bons tests, etc. Sinon, ils ont besoin d’un coup de pouce et qu’on leur fasse comprendre que les tests sont plus importants que le code qu’il / elle produit.

Oh oui, et pour ce qui est du plugin, oubliez ça, vous ne devriez avoir que le même commentaire de code que celui que vous faites.

Answer 3

Vous devez vraiment spécifier le langage / framework que vous utilisez.

Dans le cas le plus simple, je suppose qu'il devrait être facile de détecter les chaînes assert (true) avec un simple grep -ping.

Answer 4

Vous pouvez toujours essayer une série de tests avec garbage pour les valeurs de configuration de l'application.

Tous les tests réussis sont-ils suspects?

Answer 5

Plutôt que de passer du temps à rechercher des tests qui ne peuvent pas échouer, pourquoi ne pas étendre un peu les tests, faire échouer le code de nombreuses façons. Ce serait

• Montrez-lui comment rédiger de meilleurs tests
• Obligez-le à corriger son code et empêchez d'autres codes d’être archivés

Un morceau de code buggy que vous devez utiliser serait un bon point de départ - vous devez être sûr que cela fonctionne ...

Answer 6

Prenez l'interface qu'il teste et réduisez-la à sa forme la plus simple. En d'autres termes, prenez les signatures classe / méthode et ajoutez uniquement le code nécessaire pour compiler au-delà. Exécutez ses tests contre cela. Demandez-lui pourquoi ses tests réussissent quand le programme ne fait rien.

Answer 7

La révision de code, réalisée par au moins deux développeurs déjà testés, est probablement le meilleur moyen de convaincre le développeur en question de constater que le test unitaire automatisé n’est vraiment ni difficile ni inhabituel. Avoir deux développeurs testés infectés à chaque examen renforcera l’importance des tests unitaires de qualité pour lui. En outre, lui attribuer des analyses du code d’un autre développeur, qui est bien testé, l’aidera à apprendre à effectuer des tests unitaires.

Vous devriez jeter un coup d'œil aux tests de mutation pour détecter les tests faibles. Nester , (l'équivalent .Net de Jester ) est un outil que vous pouvez trouver utile.

Dites-nous comment vous allez!

Mise à jour: je suis tombé sur: "Pourquoi la plupart des développeurs n'écrivent-ils pas encore des tests unitaires" et ont pensé qu'il serait bon de lire ici aussi.

Answer 8

Je pense que vous devez d'abord lui faire écrire un test d'échec. Essayez de le prendre dans cette habitude. Les nouveaux utilisateurs des tests unitaires ont souvent du mal à les écrire.

De plus, certains outils peuvent vous aider à "explorer tous les chemins de code possibles". Je vous suggère d’examiner PEX , ce qui générera des tests automatisés, et cela cassera très probablement son code ... Bien que cela puisse ne pas être une âme optimale, essayez de promouvoir le base de code.

Demandez à vos développeurs de se connecter à un programme, il est beaucoup plus difficile d’être "fainéants". lorsque vous travaillez avec quelqu'un d'autre sur la même fonction, cela étendra la propriété du code. Vous semblez ne pas le faire, puisque vous parlez de son " code. Cela peut supposer combien vous pouvez accomplir si deux personnes travaillent au même travail, cela augmentera considérablement la qualité.

De plus, les tests unitaires ne sont pas le Saint Graal pour résoudre tous les problèmes ... Ils devraient être l’un des outils à votre disposition.

Quelle est votre exigence en matière de couverture de code?