TESTER LES IHM

Comme beaucoup de monde, nous nous sommes cassé les dents sur l'automatisation des tests d'IHM. Dommage que je ne connaissais pas à l'époque le petit pattern que Michael Feathers a décrit dans ce court article: The Humble Dialog Box.
Dans sa démarche, la couverture par les tests automatisés n'est pas exhaustive, mais elle est déjà bien optimisée. Et puis sa solution a le mérite de la simplicité. Ce n'est pas rien...

Son principe est de ne mettre aucune logique dans les classes des widgets. Ce code est extrait du widget pour être mis dans une classe écrite en Test First Programming et dépendant d'une interface du widget.
Pour les besoins des tests automatisés, l'interface du widget est implémentée dans la fixture du test unitaire par un stub ou un mock (au choix selon les goûts).
En revanche, pour l'application en production, l'interface du widget est implémentée par un vrai widget qui a l'humilité de déléguer le traitement de tous les évènements graphiques à une instance de la classe "intelligente". Ce code de délégation n'est pas testé de manière automatisé mais le risque est limité à du code "humble".

Michael Feathers est un testeur héroique. Il se confronte aux pires cas. Après le test automatisé des IHM, il s'est attaqué au test automatisé du "legacy code", c'est à dire des applications écrites sans tests. Il y a consacré un livre: Working Effectively With Legacy Code.

J'étais déjà tombé par hasard sur The Humble Dialog Box il y a quelques années mais je l'avais négligé à tord. C'est ma lecture du moment xUnit Test Patterns: Refactoring Test Code qui m'a redirigé vers cet article. Je reparlerai plus tard de ce livre assez génial qui impacte beaucoup ma manière de tester en ce moment.