Comment utiliser OpenAI Codex pour des tests de bout en bout | par Julio Almeida

Automatisation de l’automatisation

Cette semaine, j’étais en train de planifier et de choisir quel type d’outil de test de bout en bout devrais-je utiliser pour un certain projet, même si mon cerveau basé sur le cyprès crie tout le long. Mais le cri est toujours plus élevé concernant OpenAI, utilisant chaque situation pour crier. Comme vous pouvez conclure la question ici est:

« Pouvons-nous construire un outil agnostique qui convertit le comportement de test en plusieurs frameworks ? »

Voyons voir!

Ces outils de test de bout en bout n’ont pas la meilleure répartition des parts de marché à mon avis, mais d’après ce que j’ai vu, certains outils sont à l’honneur :

• Sélénium : prend une grande part de part de marché, mais ce n’est pas connu pour être le meilleur outil. C’était le premier à apparaître et donc toujours en première position. Dans ce type de situation, la plupart des gens parleront de Webdriver sélénium, car le produit est un début simple pour une autre extension comme celle mentionnée.
• cypress : Une nouvelle version, beaucoup plus conviviale à utiliser, construite au-dessus de Node qui apporte plusieurs outils et une communauté avec elle. Avoir des limitations de performances par rapport à Selenium, mais généralement, ce n’est pas le but. Les pipelines CI/CD sont généralement très bon marché et la vitesse n’est pas le nom du jeu, donc je ne serais pas inquiet.
• puppeteer : C’est un module utile pour les tests et le scraping web, également facile à utiliser. N’a pas l’infrastructure de test de cypress, mais n’était pas l’objectif principal.
• Un outil Microsoft, et le petit nouveau du bloc. Très similaire à Cypress, mais vous n’êtes pas coincé dans l’écosystème, ce qui est bien, car cypress vous donne de beaux outils et quelques limitations qui vont avec.

Il existe d’autres outils sur le marché, mais avec une sorte de verrouillage du fournisseur, ce n’est pas le sujet ici.

Comme je viens de le mentionner, le marché propose deux options : les tests orientés code (conviviaux pour les développeurs) ou les tests orientés utilisateur (sans code). Le premier a tendance à être open-source ou donne la liberté quant à la façon de l’exécuter. Doit être fait par un développeur. Le second, vous êtes limité par l’écosystème, ne sachant rien de ce qui se passe dans les coulisses, mais un responsable sans aucune connaissance en codage pourrait également effectuer l’intégralité des tests par lui-même, ce qui aurait du sens pour les entreprises plus professionnelles. Aucune de ces options ne vous donne la possibilité d’avoir le gâteau et de le manger aussi, comme utiliser un outil low-code qui génère le code puis l’utiliser ailleurs. OpenAI peut résoudre ce problème et même projeter un produit potentiel.

Tout d’abord, soyons clairs sur ce que nous voulons avec une image :

Cette image de gauche contient une simplification excessive du fonctionnement actuel des langages modernes, ou plutôt du fonctionnement de .NET/Java. Ces langages sont convertis en un langage intermédiaire (IL/Bytecode) qui ressemblerait à un pseudo-assemblage, qui ne serait converti en assemblage qu’une fois le code exécuté sur une certaine machine avec le framework approprié installé.

L’idée ici est la même. Nous ne voulons pas une génération statique de tests à chaque fois, mais nous voulons une interface simple (par exemple, cliquer sur l’interface) qui serait ensuite utilisée pour créer notre texte pour l’OpenAI. Ce document serait ensuite exécuté pour créer des tests dans cypress ou toute autre option.

La nouvelle mise à jour qui est sortie cette semaine publie une nouvelle version de davinci, ainsi que de nouvelles fonctionnalités, mais nous allons nous en tenir à l’achèvement maintenant.

C’est la structure du document, magnifiquement simple. Une phrase indiquant quoi faire avec le moteur, suivie de l’URL à tester. Ensuite, chaque test est séparé par une séquence d’arrêt et contient une phrase simple qui explique ce que le client veut faire. Dans notre idée, ce message serait généré après que l’utilisateur ait cliqué sur un bouton par exemple (à l’aide d’une interface hypothétique). Après tout, les tests sont écrits puis nous pouvons générer le code.

Cela aide énormément d’avoir la première partie du test de fin d’études. Améliore le travail et les performances x100.

J’ai récemment fait un modèle pour tester certaines choses à utiliser à l’avenir. C’est ici et déployé prêt à jouer. Concevons deux tests :

• Un test pour écrire dans chaque question, enjamber chaque question, puis effacer le contenu. Assurez-vous également que le bouton est désactivé lorsque les entrées sont vides.
• Une épreuve qui change de thème

Comme vous pouvez le voir, cela fonctionne extrêmement bien, mais si cela était prêt pour la production, vous auriez besoin d’un arbre de décision assez complexe pour couvrir toutes les phrases, sinon votre code serait illisible.

Notez que chaque ligne de texte est une ligne de code, écrite de manière à avoir un sens pour l’IA. Parfois, je mentionne l’identifiant du composant, ainsi que le texte qu’il contient. Mais le meilleur est le stepper, je l’ai expliqué comme un tableau, et il l’a compris, sinon, il aurait fait un code avec un accès direct, ce qui serait assez moche.

Voyons donc le résultat :

Fonctionne bien et a l’air propre. Cela pourrait être fait pour tout, pour Jest ou tout autre outil de test unitaire. j’ai aussi converti xUnit tests à Jest et a fonctionné parfaitement!

OpenAI devient quelque chose auquel je ne m’attendais pas avant la sortie de GTP-4. La première version était un peu disquette, essentiellement un emballage pour votre réglage fin. Il semble de plus en plus conscient, corrige les erreurs et fait même ce que vous voulez, sans trop d’essais et d’erreurs.

Cet article est un teaser pour quelque chose dont on parlera pour une éventuelle startup puisque le business model a du sens, et correctement je détiens les compétences pour le faire une fois que le monde ira mieux.