Construire autour du cœur

Les mêmes questions de propriété réapparaissent quand nous ajoutons un document, un composant ou un outil de développement.

Conventions de notation

Les noms de fonctions, types, commandes, options et fichiers sont composés en chasse fixe, par exemple describe, wf test ou main.cpp. L’italique introduit un terme lors de sa définition. Les blocs de code donnent les extraits à saisir ; le texte qui les précède précise leur emplacement et leurs prérequis.

Un nœud est de l’autre côté

Avec ui.document(), le code C++ peut demander la création d’un bouton et modifier son texte. Il serait pourtant trompeur d’imaginer que l’objet nœud contient le bouton lui-même : celui-ci appartient au document du navigateur. Le nœud C++ nous permet de le désigner.

Les opérations sont regroupées en lots, envoyées à la page et appliquées par un interpréteur JavaScript dans les îles qu’elle a prêtées. Les deux côtés conservent les noms et les identités nécessaires pour parler des mêmes éléments.

Si nous supprimons un sous-arbre ou libérons une île, ces identités ne désignent plus des éléments utilisables. De même, un rechargement donne un nouveau document. Une modification faite directement dans la page, hors de ce mécanisme, n’est pas automatiquement rapportée au C++.

Construire un formulaire, prêter une île

Un formulaire ajoute une manière de décrire ce que nous voulons afficher. Nous donnons les champs, leurs libellés, leurs bornes et leurs fonctions d’accès ; le code du formulaire utilise ensuite le document pour construire les contrôles. Cette description ne crée pas à elle seule un nouveau type transportable par le pont.

Les descriptions sont utilisables en C++23. La réflexion C++26 constitue une façon optionnelle de les obtenir. Elle ne change pas le rôle de la couche qui construit le formulaire.

Avec React, une autre question apparaît : qui peut retirer les éléments ? Le composant Island prête un sous-arbre au C++. Avant de démonter ce composant, React et C++ doivent coordonner sa libération. Sans cet accord, l’un pourrait retirer le panneau pendant que l’autre s’en sert encore.

Demander la même opération par deux chemins

Nous savons lancer les tests depuis le terminal développeur. Pour les lancer depuis un agent, il serait possible de lui faire lire le texte du terminal. Nous dépendrions alors de la présentation des messages, alors que le programme connaît déjà la commande et son résultat.

Le lanceur d’automatisation réutilise donc le moteur d’opérations du terminal. Un contrat natif décrit les arguments, les résultats, les erreurs et les autorisations. L’interface JSON en ligne de commande et l’adaptateur MCP exposent ce contrat.

Un appel à webfront.start nous donne un identifiant ; webfront.result permet de suivre ce qui a effectivement eu lieu. Une commande autorisée peut encore échouer. Le contrôleur doit aussi décider quoi faire si le terminal et l’agent demandent deux opérations incompatibles, et limiter la quantité de sortie conservée.

Le test reste lorsque l’agent s’en va

Un agent peut nous aider à écrire un test de parcours. Le résultat utile est alors le test que nous pourrons relancer demain, y compris sans cet agent.

JasmineTest charge les spécifications dans la page d’une application de test. La fonction CMake correspondante les associe au programme ; le lanceur récupère leur rapport et en fait un résultat CTest. La page, les callbacks et le moteur de rendu restent ceux de l’application. MCP n’intervient pas dans cette exécution.

Pour comprendre le lanceur, regardons aussi ce qui arrive si le rapport manque ou si la page ne répond plus. Un test réussi nous renseigne sur le parcours observé. Un échec correctement signalé nous permet de nous fier à la recette qui l’exécute.

Vérifier sa compréhension

MCP est-il nécessaire à l’exécution des parcours Jasmine en CI ?

Aller à la documentation source ↗