Une plateforme commune pour écrire des tests centrés sur les comportements métier, puis les préparer et les exécuter dans un parcours guidé.
Chaque test pouvait nécessiter sa propre préparation : accès aux API, authentification, données, sélecteurs, attentes, dépendances et rapports. Les équipes passaient du temps à réunir les conditions du test avant de décrire ce qu’il devait vérifier.
Cette complexité se retrouvait dans la prise en main, le code dupliqué, la maintenance et les différences entre exécution locale et intégration continue.
Architecture et développement des bibliothèques de test et de l’outillage d’exécution, avec intégration et adaptation des composants CI. Mon travail couvre les interfaces proposées aux auteurs de tests, les services techniques partagés, les environnements conteneurisés, les interfaces de lancement et de restitution, ainsi que la documentation qui accompagne leur adoption.
J’ai conçu et développé le socle de test partagé et des intégrations de QaaS, en collaboration avec les ingénieurs des équipes contributrices.
Les auteurs de tests assemblent des capacités déjà préparées dans la plateforme. Le socle prend en charge les détails techniques qui seraient autrement recopiés dans chaque scénario.
Les fixtures préparent les clients et les données de test. Des assertions partagées vérifient les réponses et les objets métier. Les imports publics donnent accès à ces capacités sans imposer de parcourir la structure interne des packages.
Les commandes métier regroupent des étapes récurrentes, comme l’ouverture de session et les parcours de publication. Les sélecteurs, les attentes et les codes de statut techniques sont maintenus derrière ces commandes.
Les fabriques de scénarios assemblent des opérations réutilisables, des profils de charge, des vérifications et des métriques. Les couches HTTP et d’instrumentation partagées harmonisent les appels et les mesures.
Les métadonnées, décorateurs, registres et plugins pytest organisent la déclaration, la sélection et l’exécution des scénarios. Une opération partagée peut ainsi évoluer à un seul endroit, puis être diffusée avec la plateforme.
Scénario API illustratif : créer un fichier média et vérifier son état d’envoi. Les clients partagés, fixtures de données et assertions prennent en charge la préparation récurrente.
def test_asset_upload():
settings = load_settings()
token = authenticate(settings)
client = build_client(settings, token)
payload = build_asset_data()
created = client.create_asset(payload)
assert created.status == 201
asset_id = created.body["id"]
client.mark_uploaded(asset_id)
current = client.get_asset(asset_id)
assert current.body["upload_state"] == "ready"def test_asset_upload(asset_client, asset_data):
created = asset_client.create(asset_data)
assert_asset_created(created)
asset_client.mark_uploaded(created.id)
current = asset_client.get(created.id)
assert_upload_state(current, "ready")La fixture fournit un client déjà configuré ; la préparation des données et les assertions ont leur propre implémentation partagée. L’auteur lit la séquence métier et les mainteneurs gardent accès aux mécanismes sous-jacents.
Les images Docker regroupent le moteur et ses dépendances logicielles. Les profils Compose couvrent le développement, le débogage, la collecte et l’accès au shell ; Cypress propose aussi un accès graphique via noVNC.
Les lanceurs préparent la configuration, les conteneurs, les volumes montés et l’emplacement des résultats. Le diagnostic Docker, les caches de dépendances et la gestion des utilisateurs et permissions répondent aux problèmes récurrents d’installation.
La CI construit et publie les images, exécute les contrôles configurés et publie la documentation. Un lanceur k6 génère des Jobs Kubernetes et permet de suivre leur état, de consulter leurs journaux et de les nettoyer.
Les profils de la plateforme prennent en charge macOS, Linux et Windows via WSL2. Les conteneurs fournissent Python, Node et les dépendances navigateur ; la préparation du poste tient compte du réseau, des droits, des ressources et de l’architecture processeur.
QaaS comprend aussi les interfaces utilisées pour lancer et comprendre un test. Les points d’entrée traduisent un contexte et une sélection de tests en paramètres du moteur, configuration des conteneurs et emplacements de résultats.
Journaux structurés, réponses API lisibles, statut et durée de chaque test. Les composants de synthèse regroupent les tests réussis, échoués et ignorés, avec un accès au rapport.
Un formateur de terminal dédié organise l’heure, le type, le contexte et le message, distingue les phases d’exécution et propose quatre niveaux : silencieux, normal, détaillé et débogage. Captures d’écran et vidéos facilitent l’investigation.
L’API Tester de VS Code intègre la sélection des endpoints Swagger, les champs de requête et l’historique dans l’environnement de développement.
Une entrée de la plateforme telle que make cys-cli-showcase int smoke sélectionne les scénarios par métadonnées et délègue la configuration du lancement. Les auteurs peuvent se concentrer sur le scénario et son résultat.
Le générateur récupère les contrats OpenAPI dans Backstage, le catalogue interne des services, puis produit des clients Python. Les équipes réutilisent des modèles typés de requête et de réponse, ce qui réduit le travail propre à chaque intégration.
Les clients générés fournissent un accès typé aux services. Les auteurs de scénarios y associent les données métier et les assertions.
Une fabrique assemble le client généré adapté avec sa configuration et son authentification. Les intégrations communes à Vault et OIDC permettent de réutiliser ces accès entre services et équipes.
Les environnements de développement incluent une instance Vault locale. Les adaptateurs partagés prennent en charge la configuration des accès en dehors du scénario métier.
Les environnements préparés et les parcours guidés ont ramené le démarrage d’environ deux semaines à deux heures.
Découvrir l’exemple de prise en main →Environ 70 % de lignes en moins grâce aux fixtures, aux assertions partagées et aux clients préparés.
Voir la comparaison de scénarios →Une interface de recherche et d’export de sorties musicales ramenée à deux appels Cypress : une connexion et une commande métier.
Voir l’exemple d’interface →La préparation mutualisée garde les scénarios lisibles et facilite la maintenance des comportements récurrents. Contexte des chiffres →
Bibliothèques modulaires, services partagés, commandes de lancement guidées, environnements conteneurisés, métadonnées, sorties personnalisées et assistant documentaire local constituent les fondations de la plateforme.
Un format commun de demande et un catalogue de scénarios permettraient de choisir une vérification métier, une cible et un profil, puis de suivre le résultat pour les tests front, API et de performance.
Les adaptateurs des moteurs traduiraient ce contrat commun en exécution et en vérifications propres à chaque outil.