Les simulacres et la couverture de test élevée sont-ils importants?

Question

Mock frameworks, par exemple EasyMock, simplifiez l’installation de dépendances factices. Cela dit, les utiliser pour vérifier comment les différentes méthodes portant sur des composants particuliers sont appelées (et dans quel ordre) me semble mauvais. Cela expose le comportement à tester en classe, ce qui rend plus difficile la maintenance du code de production. Et je ne vois vraiment pas l'avantage; mentalement, j'ai l'impression d'avoir été enchaîné à une grosse balle.

J'aime beaucoup tester uniquement contre l'interface, en donnant des données de test en entrée et en affirmant le résultat. Mieux encore, utiliser un outil de test qui génère automatiquement des données de test pour vérifier une propriété donnée. par exemple. ajouter un élément à une liste et le supprimer immédiatement donne la même liste.

Sur notre lieu de travail, nous utilisons Hudson qui fournit une couverture de test. Malheureusement, il est facile de devenir aveuglément obsédé par le fait que tout est testé. Je suis fermement convaincu qu'il ne faut pas tout tester si l'on veut être productif également en mode maintenance. Un bon exemple serait celui des contrôleurs dans les frameworks Web. Comme ils ne devraient généralement contenir que très peu de logique, tester avec un modèle de structure que le contrôleur appelle telle ou telle méthode dans un ordre particulier est absurde à mon avis.

Chers SOers, quelles sont vos opinions à ce sujet?

Answer 1

Cela dépend de la manière dont vous modélisez le ou les domaines de votre programme.

Si vous modélisez les domaines en termes de données stockées dans des structures de données et de méthodes lisant les données d'une structure de données et stockant les données dérivées dans une autre structure de données (procédures ou fonctions selon le mode de fonctionnement ou de procédure de votre conception), alors les objets fictifs ne sont pas appropriés. Ainsi appelé "basé sur l'état" le test est ce que vous voulez. Le résultat qui vous tient à cœur est qu’une procédure place les bonnes données dans les bonnes variables et qu’elle appelle cela pour que cela se produise n’est qu’un détail de la mise en œuvre.

Si vous modélisez les domaines en termes de protocoles de communication de transmission de messages avec lesquels les objets collaborent, alors ces protocoles vous intéressent et les données que les objets stockent pour coordonner leur comportement dans les protocoles dans lesquels ils jouent des rôles ne sont que des implémentations. détail. Dans ce cas, les objets fictifs sont le bon outil pour le test basé sur le travail et les états les lient trop étroitement aux détails d'implémentation non importants.

Et dans la plupart des programmes orientés objet, il existe un mélange de styles. Certains codes seront écrits purement fonctionnels, transformant des structures de données immuables. Un autre code coordonnera le comportement des objets dont l'état interne et caché change au fil du temps.

En ce qui concerne la couverture de test élevée, cela ne vous dit vraiment pas grand chose. Une couverture de test faible indique les tests inadéquats, mais une couverture de test élevée ne vous indique pas que le code est correctement testé. Les tests peuvent, par exemple, parcourir des chemins de code et augmenter ainsi les statistiques de couverture, sans pour autant faire d'assertion quant à leur comportement. En outre, ce qui compte vraiment, c’est la manière dont les différentes parties du programme se comportent de manière combinée. Si vous voulez vérifier que vos tests testent réellement le comportement de votre système, vous pouvez utiliser un outil de test de mutation. C’est un processus lent. C’est donc quelque chose que vous exécuteriez dans une version nocturne plutôt que lors de chaque enregistrement.

Answer 2

J'ai lu 2 questions:

Quelle est votre opinion sur le fait de tester le fait que des méthodes particulières sur des composants sont appelées dans un ordre particulier?

Je suis tombé dans le pétrin par le passé. Nous utilisons beaucoup plus de "stubbing". et beaucoup moins "moqueur" ces jours-ci. Nous essayons d'écrire des tests unitaires qui testent une seule chose. Lorsque nous faisons cela, il est normalement possible d’écrire un test très simple qui stubs interactions avec la plupart des autres composants. Et nous affirmons très rarement la commande. Cela contribue à rendre les tests moins fragiles.

Les tests qui testent une seule chose sont plus faciles à comprendre et à maintenir.

De plus, si vous vous retrouvez confronté à de nombreuses attentes concernant les interactions avec de nombreux composants, le code que vous testez peut de toute façon poser problème. S'il est difficile de maintenir des tests, le code que vous testez peut souvent être remanié.

Devrait-on être obsédé par la couverture du test?

Lorsque j'écris des tests unitaires pour une classe donnée, je suis plutôt obsédé par la couverture de tests. Il est très facile de repérer des comportements importants que je n'ai pas testés. Je peux également émettre un jugement sur les bits que je n'ai pas besoin de couvrir.

Statistiques de couverture globale des tests unitaires? Pas particulièrement intéressé tant qu'ils sont élevés.

Couverture de 100% des tests unitaires pour tout un système? Pas intéressé du tout.

Answer 3

Je suis d'accord - je suis favorable à une tendance à la vérification d'état, plutôt qu'à la vérification du comportement (interprétation lâche de TDD classique tout en utilisant les doublons de test).

Le livre L'art des tests unitaires propose de nombreux conseils judicieux dans ces domaines.

Une couverture de test à 100%, une interface graphique, des getters / setters ou tout autre code dépourvu de logique, etc. ne semblent pas offrir un bon retour sur investissement. TDD fournira une couverture de test élevée dans tous les cas. Testez ce qui pourrait casser.

Answer 4

J'avais posé une question similaire Combien de tests unitaires est un Good Thing , qui pourrait aider à donner une idée de la variété des niveaux de test que les utilisateurs jugent appropriés.

Answer 5

1. Quelle est la probabilité que, lors de la maintenance de votre code, un employé junior rompt la partie du code qui exécute les "appels du contrôleur de telle ou telle méthode dans un ordre particulier"?

2. Quel est le coût pour votre organisation si une telle situation se produisait - interruption de production, débogage / correction / nouvelle test / nouvelle version, risque juridique / financier, risque de réputation, etc.?

Maintenant, multipliez les n ° 1 et n ° 2 et vérifiez si votre réticence à obtenir une couverture de test raisonnable en vaut la peine.

Parfois, ce ne sera pas le cas (c’est pourquoi, dans les tests, il existe un concept de point de rendement décroissant).

E.g. Si vous maintenez une application Web qui n'est pas essentielle à la production et que 100 utilisateurs disposent d'une solution de contournement si l'application est défectueuse (et / ou peut effectuer une restauration simple et immédiate), passer 3 mois à tester complètement la couverture de cette application est probablement non -sensical.

Si vous travaillez sur une application dans laquelle un bug mineur peut avoir des conséquences de plusieurs millions de dollars ou davantage (logiciel de navette spatiale ou système de guidage pour missile de croisière), les tests approfondis avec couverture complète deviennent beaucoup plus sensuels. .

De plus, je ne suis pas sûr de lire trop votre question, mais vous semblez vouloir dire que les tests unitaires activés pour le mocking excluent en quelque sorte les tests fonctionnels d'intégration / d'applications. Si tel est le cas, vous avez raison de vous opposer à une telle notion: les deux méthodes de test doivent coexister.