Lire la transcription en français
0:00 · Ouverture
Une courte histoire sur le test de systèmes SAP, racontée par trois personnages : un agent, un messager, un système réel. Et sur un état d'esprit, le Spec-Test-Driven Development (STDD) : ce que l'on teste est d'abord observé sur le système réel.
0:17 · Les personnages
Stedd est l'agent IA. Un chapeau par métier : planifier, générer, vérifier, réparer. MCP est le messager : il porte les requêtes à Robot Framework et rapporte les réponses. Terra est le système SAP réel. Ils sont deux : Terra 2023, notre cible, et Terra A4H, son jumeau.
0:36 · La méthode habituelle
La plupart des automatisations de test partent de ce que l'on suppose du système : un document, un souvenir, une capture d'écran. Le test est écrit d'après la supposition, sans regarder le système. Il s'exécute. Il passe au vert. Mais le système réel n'a jamais été interrogé : la tuile n'existe pas, l'application vit ailleurs. Vert, et faux.
1:00 · De TDD à STDD
Vous connaissez peut-être TDD : rouge, vert, refactor. Le test d'abord, le code ensuite. Le STDD applique la même logique une brique plus tôt : la spec vient d'abord. En théorie, une spec est verte par défaut : personne ne la teste. Le STDD la met à l'épreuve du système réel : rouge là où elle se trompait, verte une fois observée. Seulement ensuite vient le test.
1:25 · Trois maillons
Le STDD est une chaîne de trois maillons. Chacun pilote le suivant, et chacun est contrôlé par un script. 1 · La spec, écrite en langage humain, puis confrontée au système réel par un agent, avant tout code. 2 · Le test, dérivé de la spec telle qu'elle a été observée, et scellé par l'empreinte de la spec. 3 · La bibliothèque, développée d'après ce dont le test a besoin : jamais un contournement caché dans le test. Trois scripts : agent_contract.py, check_spec_sync.py, check_conventions.py. Ils échouent bruyamment.
1:59 · Un cas réel : le scénario 4
Un cas réel : le scénario 4, sur Terra 2023 (ABAP Platform 2023) : créer un voyage avec une réservation, dans Fiori. La spec est un brief en langage courant : sept lignes, aucun code. Toute forme convient : un objectif, une user story, un scénario BDD… Celui-ci suppose deux choses : une tuile du Launchpad ouvre l'application, et la cible est la démo cap-sflight.
2:25 · Maillon 1 · la spec face au système réel
Maillon 1. L'agent planner, un LLM, confronte le brief au système vivant, avant d'écrire le moindre test. Il ne devine pas. Il envoie MCP : Robot Framework pilote SAP pour de vrai, le LLM ne fait que lire les réponses. Hypothèse 1, une tuile du Launchpad : 62 intents vérifiés sur Terra 2023. Aucun n'ouvre d'application de voyage. Réfutée. Hypothèse 2, cap-sflight : une application CAP locale sur le port 4004. Pas cette cible. Ici, l'application est en RAP : /DMO/UI_TRAVEL_D_D. L'application réelle existe pourtant : 4 136 voyages, et le serveur génère un aperçu Fiori Elements… derrière une erreur HTTP 500. La solution se lit dans le code source du serveur lui-même : l'adresse est obscurcie, +20 par caractère. Décodée : HTTP 200. Avant d'écrire quoi que ce soit : peut-on défaire ? Abandonner un brouillon exige If-Match. Essayé, puis prouvé : réversible. Côte à côte : le brief tel qu'il était supposé, la spec telle qu'elle a été observée sur Terra 2023, ligne par ligne. Pas de tuile, une autre cible, une devise obligatoire que l'écran cache, un identifiant réattribué : rien de tout cela ne se devinait. 12 écarts au total, chacun appuyé par une mesure. Un humain les relit avant que rien ne soit généré. La spec telle qu'observée, avec ses 12 écarts au brief, est écrite, scellée par un sha256 et relue par un humain. Elle devient la source de vérité. À retenir : la spec est observée, pas supposée. Les surprises arrivent avant les tests, pas après.
4:17 · Maillon 2 · le test, dérivé de la spec
Maillon 2. L'agent generator transforme la spec observée en suite Robot Framework, dans un vocabulaire métier. Chaque étape est d'abord exécutée sur Terra 2023, via MCP, et n'est écrite qu'une fois qu'elle fonctionne. Aucun localisateur deviné. La suite porte l'empreinte de la spec, son sha256 : le test sait exactement de quelle spec il est dérivé. Modifiez la spec sans régénérer, et check_spec_sync.py refuse l'exécution. Régénérée, relue : de nouveau en phase. Un script, pas une promesse. À retenir : rien n'est écrit qui n'ait d'abord tourné, et la suite reste scellée à sa spec.
5:02 · Maillon 3 · le test pilote la bibliothèque
Maillon 3. Parfois le test a besoin de quelque chose que la bibliothèque ne sait pas encore faire : un format de date, un en-tête manquant… …alors le manque devient un keyword de la bibliothèque, avec son test unitaire. Jamais un contournement dans le test : check_conventions.py veille. Six capacités, chacune avec son test unitaire : des dates saisies au format propre au champ, If-Match, la release lue par HTTP, l'adresse de l'aperçu… La bibliothèque est publiée sur PyPI, sous le nom robotframework-sapfx. Le projet suivant hérite des six gratuitement. À retenir : le test pilote la bibliothèque, et chaque manque comblé là aide le projet suivant.
5:53 · Un vérificateur indépendant
Stedd change de chapeau. Le vérificateur lit le plan, la suite et les preuves. Il n'exécute rien. Son premier verdict sur la suite verte : non vérifié. 13 réserves, dont 3 bloquantes. Les 13 corrigées, puis une contre-revue : humain requis, 7 points de plus. Corrigés aussi. Chaque garde doit être vue refuser. D'abord la référence, sur Terra 2023 : release 758, 58 services. Puis la suite est pointée sur Terra A4H, exprès : même identifiant système, même nom d'hôte que Terra 2023. Comparaison : 754 ≠ 758, 38 ≠ 58, aucun runtime UI5. Chaque garde refuse. Vu, pas supposé. Seconde provocation : un brouillon planté à la main sur Terra 2023. La garde l'a épargné, le nettoyage l'a supprimé. Trouvé, corrigé, rejoué. À retenir : une garde que personne n'a vue refuser ne prouve rien.
6:58 · Résultat
Résultat : 7 tests sur 7 sur Terra 2023. Chaque voyage créé est supprimé, et sa disparition prouvée, entité par entité. La génération a coûté 1,67 M de tokens LLM, une fois. Le rejeu coûte zéro token : du Python pur, en moins de cinq minutes.
7:19 · Quand le système change
Un cas réel, le 1er septembre : le Demo Kit public d'OpenUI5 a changé de shell du jour au lendemain. Pas une ligne de notre dépôt n'a bougé. La campagne tombe à 8 sur 12. Diagnostic du healer : pas un localisateur, le parcours lui-même a changé. La spec est marquée PÉRIMÉE. Le planner retourne sur la cible réelle, réécrit la spec d'après ce qu'il mesure, et la suite suit : 12 sur 12, de nouveau scellée. L'autre branche, testée à l'aveugle sur Terra A4H : une dérive de localisateur injectée exprès. Le healer lit l'écran vivant… …et corrige une ligne de resources/. Tests touchés : zéro. Rejeu : 7 sur 7. Le STDD est une boucle, pas un pipeline. Le healer répare resources/, jamais le test. Un parcours qui change remonte à la spec, et la suite suit.
8:15 · Conclusion
La spec d'abord, en langage humain. Le test depuis la spec. La bibliothèque depuis le test. Chaque maillon gardé par un script. Observé, dérivé, gardé, et maintenu en vie quand le système change. Merci d'avoir marché avec Stedd, MCP et Terra.
