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.

LE GOUROU (V1)

Le gourou s'est rendu indispensable pour l'organisation. Il maitrise un savoir faire incontournable. Les développeurs viennent le consulter dans son antre. Il dispense conseils et solutions techniques à la demande.

Il intervient rarement à plein temps sur un projet mais plutôt ponctuellement lors d'opérations de sauvetage.

Le gourou est une évolution de l'architecte, du moine codeur ou plus rarement du pragmatique. Plus particulièrement, il est l'évolution ultime du moine codeur. A force de se spécialiser dans une technologie stratégique et par rétention d'information, le moine codeur sécurise son avenir en devenant enfin un gourou.

TRAVAIL EN ÉQUIPE

Généralement, le gourou intervient ponctuellement dans les équipes. Il détient une position transverse à tous les projets et à toutes les équipes. Cette situation présente l'inconvénient de la solitude et l'avantage de ne jamais couler avec un projet en difficulté.

RELATIONS AVEC LES AUTRES DÉVELOPPEURS DE L'ÉCOSYSTÈME

Le gourou se moque doucement du folklore du collectiviste.

LE STAGIAIRE (V1)

Le stagiaire est au plus bas de l'échelle sociale dans l'organisation. Il est de passage et corvéable à merci. Parfois son travail est utilisé.

LE TRAVAIL EN ÉQUIPE

Le stagiaire est rarement réellement intégré à l'équipe.

RELATIONS AVEC LES AUTRES DÉVELOPPEURS DE L'ÉCOSYSTÈME

Le stagiaire est ignoré par beaucoup, sauf par son maitre de stage (quoique...) et par le collectiviste.
Il retrouve d'autres stagiaires lors des pauses et des repas.

LE COLLECTIVISTE (V1)

Le collectiviste vit pour l'équipe. Selon lui, les individus se réalisent dans l'équipe. L'efficacité de l'équipe est la clé de la réussite du projet. Il est constamment à la recherche de pratiques permettant à l'équipe de s'améliorer. Le consensus, l'auto-organisation et l'amélioration continue sont sacrés.

Le collectiviste a trouvé son salut dans le développement logiciel Agile. Voilà enfin une démarche centrée sur l'humain. Bien sur il est ScrumMaster ou coach Agile. S'il le pouvait, il ne ferait d'ailleurs que cela. Ses heures de gloire sont les stand-up meeting (il y en a un par jour!), les réunions de planification, de revue et LA RÉTROSPECTIVE! A l'occasion de cette réunion qu'il transforme en véritable messe, il sort de ses livres des outils anglo-saxons pour aider les équipiers à s'exprimer. Il prône de très courtes itérations. Cela multiplie la fréquence de ces moments de partage en équipe.

Certains recherchent les anti-patterns dans le logiciel et remanient vers les design-patterns. Lui détecte les anti-patterns comportementaux et remanie l'équipe vers des patterns organisationnels.

LE TRAVAIL EN ÉQUIPE

Le collectiviste mise tout sur le travail en équipe. Il est intiment convaincu que le travail de l'équipe est supérieur à la somme des contribution individuelles de ses membres. Il organise les tours de croissants le Vendredi, les rétrospectives d'itération, les repas d'équipe, les tours de tables, les pauses café en groupe, le démarrage de la bouilloire et la rotation des binômes.

RELATIONS AVEC LES DÉVELOPPEURS DE L'ÉCOSYSTÈME

Le collectiviste s'extasie devant le binôme, symbole de partage.
Le collectiviste cherche à débarrasser l'équipe du moine codeur, cet infâme individualiste..

L'HOMME/MOIS (V2)

L'homme/mois fournit un mois de développement par mois.

LE TRAVAIL EN ÉQUIPE

Les hommes/mois se cumulent. Il parait que N hommes/mois travaillant en équipe pendant 1 mois développent comme un homme/mois pendant N mois. Ceci expliquerait pourquoi certains managers raffolent des hommes/mois. Il parait aussi que l'homme/mois est un mythe, comme l'affirme un certain Brooks.

RELATIONS AVEC LES DÉVELOPPEURS DE L'ÉCOSYSTÈME

L'homme/mois apprécie l'architecte car il lui permet de faire sans penser.
L'architecte apprécie l'homme/mois car il lui permet de penser sans faire (Merci Thomas L. pour cette remarque ;o).

LE BINOME (V1)

Le binôme ne développe jamais seul. Son partenaire n'est pas son siamois, il permute volontiers. En général, il est une mutation du développeur pragmatique.

LE TRAVAIL EN ÉQUIPE

Il travaille en équipe: elle lui fournit ses partenaires.

RELATIONS AVEC LES DÉVELOPPEURS DE L'ÉCOSYSTÈME

Le binôme est un pragmatique. Il trouve que le moine codeur l'a rejeté impoliment lorsqu'il lui a proposé de binômer.
Il trouve que l'architecte travaille bien seul ...

LE PRAGMATIQUE (V1)

Le développeur pragmatique est un praticien. Il pratique les tests, le remaniement, la programmation par assertions, la programmation par contrat, l'intégration continue.

LE TRAVAIL EN ÉQUIPE

Il travaille en équipe: il sait qu'il n'arrivera jamais au bout du projet seul.

RELATIONS AVEC LES DÉVELOPPEURS DE L'ÉCOSYSTÈME

Il trouve que la conception de l'architecte n'est pas encore pertinente car non testée.
Il rappelle au moine codeur et au cowboy codeur qu'ils ont cassé le build et que leur code n'est pas couvert par des tests.