Comment ça on ne teste pas !? Bin non, ce n’est pas possible. C’est la réponse qui m’irrite le plus juste après le « on a toujours fait comme ça ». Quel est l’intérêt d’une plate-forme de tests où la moitié des jobs est en rouge ? Comment valider un tel fourbi d’erreurs ?
Dans de telles conditions il est nécessaire de connaitre par coeur les enchainements, pour opérer à des évictions, des relances, bref il est délicat et déconseillé d’automatiser ces pratiques.

Afin d’être le plus proche de la production tout en prenant en compte certaines limites des recettes, voyons donc ici un ensemble de pratiques, non pour automatiser mais pour s’y préparer. Une petite remise à plat pour éliminer tous ces incidents normaux (ça me fait mal de l’écrire). Etape nécessaire pour automatiser ses tests et tendre vers plus de Continuous Delivery.

Les transferts en interne

A la B. Mouret, si Keops est l’application qui nous intéresse, elle n’est pas la seule. Et en production elle envoie certains de ses fichiers générés vers les autres applications de la banque. Or, en recette, les autres applications ne sont pas disposées à recevoir de fichiers. Le parti a donc été pris de ne pas tester les envois de fichiers en interne.

En plus de s’écarter des mécanismes mis en oeuvre en production, cette solution ne permet pas de tester les éventuels soucis de transferts liés qui aux équipements réseaux, qui au format, qui à la transcodification. S’attacher à mettre en place ces transferts est une amélioration des tests, et des validations.

La meilleure solution est de mettre en place ces flux en recette tout comme ils le sont en production. Un travail inter-équipe est nécessaire. Il est parfois long de convaincre, et en attendant une telle mise en oeuvre globale, une solution de contournement honorable peut-être entreprise.

Tout comme nous l’avons vu dans mon article De la valorisation des constantes, il suffit de valoriser les différents serveurs de réception avec le nom d’un serveur à soi en faux-semblant avec les arborescences nécessaires à l’identique de celles des cibles. On complétera le dispositif avec une purge régulière pour économiser l’espace disque.
Un tel faux-semblant permet d’obtenir des transferts effectués, de vérifier la qualité des fichiers réceptionnés et donc modulo le nom du serveur de valider les envois.

Les transferts vers l’extérieur

Opérés via un progiciel, les transferts de fichiers vers l’extérieur ne sont pas effectué en recette de la B. Mouret. Et ce pour la simple raison que le progiciel en question n’est pas installé en recette. On se pose donc la question comment est-ce que ses évolutions et ses correctifs sont testés ? Sans remettre en cause les éditeurs de tels produits, il peut parfois apparaitre des effets de bord dans les mises en oeuvre de leur produit, une validation est toujours nécessaire.
Le coût d’une licence supplémentaire qui pourra être négociée parait bien faible en rapport d’un éventuel cafouillage sur la version de production.

D’aucuns me diront que dans leur entreprise, un tel progiciel de recette est installé mais que ce sont leurs partenaires qui n’acceptent pas leurs envois. Et moi de répondre que c’est une situation courante et que si on ne peut influer sur leur pratique, un aménagement est possible.

A l’instar des flux internes, on peut configurer son progiciel afin qu’il procède avec un faux-semblant de partenaire. Il suffit pour ça de boucler sur soi-même, définir les coordonnées des partenaires récalcitrants avec ses propres flux entrants. Astuce qui permet encore de vérifier les fichiers à réception.
Cette solution permettra en plus de vérifier les paramètres de configuration que le partenaire devrait mettre en oeuvre, et donc de pouvoir le conseiller en cas de difficulté.

Autres limites

Autre cas pratique : « Il est planté, normal, le logiciel n’est pas installé en recette ». Que ce soit un progiciel de sauvegarde de données, d’alerte téléphonique pour les astreintes, et j’en passe, certains ne sont pas installés en recette parce que jugés inutiles voire à ne pas mettre en oeuvre.

Au risque de me répéter (Cf. paragraphe précédent), c’est tout de même important d’avoir des recettes de tous ses logiciels.
Et pour ouvrir une parenthèse sur les robots d’appel d’astreintes, je dirais que le travail entrepris vers le Continuous Delivery est de minimiser le nombre d’erreurs en recette, le téléphone dédié ne devrait pas trop sonner, et quand bien même ça valide aussi le système d’alertes.

Revenons à nos brebis. Comment sortir de cette absence de logiciel ? Tout pareil : un faux-semblant.
Il suffit « d’installer » dans l’arborescence idoine un script éponyme à celui qui sera solliciter en production, mais qui n’opérera qu’à un affichage des paramètres fournis. Cette petite astuce évite un « gros rouge qui tâche » dans votre ordonnanceur, et permet de vérifier que les paramètres envoyés sont corrects.

Concrètement face à /Miracle/11.2.0/bin/AirWoman not found , vous créerez une telle arborescence avec un script AirWoman contenant par exemple : echo "$(date) - $*".

Conclusion

La solution phare exposée au travers de cas pratiques est le faux-semblant. En jouant sur ses valorisations ou en créant des fac-similés, on arrive à faire tourner une mécanique à l’identique, pour son propre domaine, de la production. C’est une étape nécessaire avant l’automatisation des tests, et c’est un palliatif à la globalisation avec tous les partenaires, équipes, logiciels, d’une recette.