De l'importance des tests automatisés

Dans un monde où l'agilité et la conformité en matière de sécurité sont de plus en plus exigées dans les infrastructures DevOps, le développement de tests automatisés est devenu crucial. On doit constamment s'assurer que les systèmes sont sécurisés, stables et conformes aux normes établies, tout en maintenant une vitesse de déploiement élevée. C'est ici que les outils de test automatisé entrent en jeu, permettant de vérifier rapidement et efficacement l'état des infrastructures et des applications. Cependant, de nombreux défis doivent être relevés pour mettre en œuvre ces tests. En voici deux illustrations.

Pour commencer, trop nombreux sont les systèmes qui ne produisent pas de données structurées, ce qui rend difficile l'automatisation ou l'évaluation de la conformité. Les tests automatisés nécessitent des jeux de données structurés et reproductibles pour fonctionner efficacement. On se retrouve donc contraint de développer en interne ou d'investir dans des outils capables de transformer les données non structurées en données exploitables.

Ensuite, la courbe d'apprentissage est très raide, surtout pour les débutants. Quand Cisco met à disposition pyATS et son extension Genie, une plateforme pour automatiser les tests sur les infrastructures réseau, arriver à une bonne compréhension des concepts de programmation tout en ayant une connaissance des spécificités des protocoles réseau demande un investissement conséquent. Cela ralentit l'adoption et l'utilisation efficace de ces outils.

Le Lab 17 « Automated testing with pyATS and Genie » est une tentative de réponse aux défis posés par l'automatisation des tests.

Les manipulations débutent par la mise en place d'une maquette avec deux routeurs qui échangent des réseaux avec le protocole OSPFv3. L'objectif de cette maquette est d'illustrer les trois états à tester.

• L'état attendu de l'infrastructure correspond à un échange de tous les réseaux connus des deux routeurs hub et spoke.
• L'état configuré correspond au fait qu'une configuration correcte a été appliquée sur chaque routeur individuellement.
• Le test de l'état opérationnel vérifie que les échanges de réseaux entre les deux routeurs sont corrects.

La progression des manipulations qui suivent la mise en place de la maquette passe par les étapes suivantes :

1. La génération de données structurées avec un tout premier code Python qui valide la communication avec un routeur à l'aide de pyATS.
2. Le test de l'état configuré avec un script Python unique qui présente la syntaxe d'une classe dont chaque méthode est un test.
3. Le test de l'état opérationnel avec un découpage en plusieurs fichiers : job, trigger et datafiles qui permettent d'accéder à un code plus efficace et réutilisable.

Si vous acceptez de vous plonger dans le scénario proposé vous verrez que ce support de travaux pratiques vous fera avancer dans la compréhension du fonctionnement et des mécanismes des tests automatisés. Ainsi, vous aurez une représentation plus précise des bénéfices apportés par la formalisation des jeux de tests.

Pour autant, il ne s'agit pas de « vendre du rêve ». Les limites de l'exercice sont bien visibles.

• Si on présente la transformation en données structurées des éléments de configuration d'un routeur, on n'utilise pas cette représentation pour les tests qui suivent. L'utilisation des données structurées engendrerait un coût supplémentaire pour le développement des tests qui suivent et rendrait le document encore plus volumineux.
• Si le protocole OSPFv3 associé aux familles d'adresses IPv4 et IPv6 est intéressant dans le sens où il utilise un mécanisme d'échange unique pour les deux familles et allège la configuration, il demeure nécessaire de maîtriser son fonctionnement pour rédiger correctement les méthodes de test.

Pour conclure, on peut dire que tout est affaire de compromis. Les étudiants peuvent aboutir à des résultats satisfaisants et mesurables avec les tableaux de bord du service web intégré à pyATS en un temps raisonnable.

L'objectif suivant est de transposer cette démarche de construction de tests à d'autres contextes, tels que le très classique « triangle OSPF » et l'intégration dans les phases d'un pipeline GitLab CI.