L’attitude du développeur pour des cas de test utiles

Les tests sont un élément incontournable du développement logiciel moderne, mais les cas de test restent au bout du compte du code écrit par des développeurs, et peuvent donc eux aussi poser problème selon les situations. Voici un article qui examine ce qui fait des cas de test « utiles » d’un point de vue orienté objet. (coréen)

L’idée essentielle est qu’un test est un [module chargé de tester d’autres modules encapsulés]. Cela signifie que les tests font eux aussi pleinement partie du code développé et qu’à ce titre, dans un paradigme orienté objet, ils doivent respecter les principes de l’orienté objet, être continuellement améliorés et refactorisés. On peut alors en déduire, au regard des principes SOLID, qu’un cas de test ne doit ni accéder à des éléments internes concrets du module testé ni en dépendre (comme des méthodes private). Ce qu’un cas de test doit vérifier, ce sont uniquement les responsabilités abstraites de ce module ; le test ne doit donc être effectué qu’à travers l’interface externe qui les reflète.

Personnellement, j’ai l’impression que c’est l’un des nombreux caps que les débutants en programmation doivent franchir. Quand j’ai moi-même appris l’orienté objet pour la première fois, j’avais bien entendu en cours qu’« il ne faut pas tester directement les méthodes private », ainsi que l’explication de cette règle, mais pour être honnête, je ne l’avais pas vraiment comprise à l’époque. Je n’ai commencé à en saisir le sens qu’un bon moment plus tard.