# Testing Farm automatise la configuration des tests pour les projets open source

_Publié le 2 novembre 2026 — https://ip73.fr/2026/11/02/testing-farm-automatise-la-configuration-des-tests-pour-les-projets/_

Testing Farm se présente comme un Testing System as a Service, une plateforme conçue pour gérer les tests des services internes de Red Hat, des services Cloud hybrides et des projets open source liés aux produits Red Hat. Ce système sert de moteur d'exécution de tests pour d'autres services ou systèmes d'intégration continue (CI), et il est facilement intégrable grâce à son API HTTP.

L'idée maîtresse de Testing Farm est d'abstraire les tests de l'infrastructure d'exécution. En utilisant un format de métadonnées de test open source, le système unifie la manière dont les ingénieurs, les développeurs en amont et les contributeurs peuvent découvrir, déboguer et lancer les tests. Cette abstraction permet aux tests de demander des exigences matérielles spécifiques sans se soucier de l'infrastructure utilisée, offrant ainsi un provisionnement transparent pour divers fournisseurs.

## L'automatisation de la configuration CI/CD

Configurer des tests automatisés pour un projet open source demandait traditionnellement de rédiger manuellement des workflows d'intégration continue fastidieux et de gérer les métadonnées de test. Testing Farm réduit cette friction en intégrant une compétence d'agentivité via Claude Code. Cette fonctionnalité permet aux développeurs d'intégrer Testing Farm sur des dépôts hébergés sur GitHub ou GitLab, qu'ils soient publics ou internes.

L'agent guide l'utilisateur pour obtenir les jetons d'API, initialiser les métadonnées TMT (Test Management Tool) et configurer les pipelines CI. Prenons l'exemple du dépôt `sclorg/ci-scripts`, qui, bien qu'ayant des suites de tests existantes avec `tox`, ne disposait pas initialement de métadonnées FMF/TMT. L'onboarding se fait en plusieurs étapes : l'agent demande de choisir la plateforme hôte (GitHub, par exemple), puis de définir les événements déclencheurs souhaités, comme les événements de *pull request* ou les *pushes* sur la branche principale. Il faut aussi spécifier la matrice d'environnements cibles, par exemple en sélectionnant Fedora-latest.

## Scripts existants et rôle de l'agent AI

Il est vrai que des scripts CI génériques existent déjà pour gérer des tâches précises. Le répertoire `sclorg/ci-scripts` contient des scripts comme `prepare-centos.sh` ou `image-test-openshift-4.sh`, qui préparent des instances OpenStack ou exécutent des tests de conteneurs pour des plateformes spécifiques comme CentOS ou OpenShift.

Cependant, l'agent Testing Farm va plus loin que l'exécution. Il automatise la *définition* des tests. Une fois les paramètres collectés, l'agent analyse la configuration de tests existante, génère les fichiers de métadonnées TMT valides (les fichiers `.fmf`) et crée simultanément la définition du workflow GitHub Actions nécessaire pour déclencher les exécutions chez Testing Farm. Ce passage d'une gestion manuelle complexe à un flux de travail intégré est significatif. Après génération, une étape de validation est requise : lancer un vérificateur (`tmt plan lint`) sur les plans de test générés pour s'assurer qu'ils respectent le schéma et les étapes d'exécution.

Le système est accessible via une interface CLI, permettant des commandes ciblées telles que « Onboard this repo to Testing Farm » ou « Add Testing Farm CI to this GitHub repository ».

## Sources

- [Testing Farm](https://docs.testing-farm.io/), docs.testing-farm.io
- [GitHub - sclorg/ci-scripts: Set of generic scripts that are run in the CI (Jenkins or any other)](https://github.com/sclorg/ci-scripts), github.com
- [Onboard your repository to Testing Farm with Claude Code](https://developers.redhat.com/articles/2026/11/02/onboard-your-repository-testing-farm-claude-code), Red Hat Developer, 2 novembre 2026