Peut-on générer les tests SAPUI5 avec l’IA ?

Objectifs

Dans ce blog, nous testons les outils IA pour écrire nos tests unitaires SAPUI5 ! Ne serait-ce pas magnifique de ne plus avoir à faire cette tâche fastidieuse ?! Nos espoirs sont grands…

L’objectif est donc de fournir un fichier contrôleur d’application SAPUI5 et de demander à une IA de générer le test unitaire de chacune des fonctions du contrôleur. L’application utilisée pour ce test est l’application de démo “Manage Products” disponible ici : https://sapui5.hana.ondemand.com/sdk/#/demoapps

Application utilisée pour ce blog

Nous profitons de ce test pour comparer la pertinence des outils SAP et des outils du marché dans cet exercice de génération des tests unitaires. Deux techniques seront donc confrontées :

• Utilisation des outils SAP : SAP Build Code avec Joule
• Utilisation des outils du marché : VS Code avec GitHub Copilot

SAP Build Code avec Joule

Prérequis :

• Configurer SAP Build Code ⇒ Ajouter SAP Build Code à votre BTP
• Importer l’application d’exemple “Manage Products”

L’assistant Joule est intégré à SAP Build Code sous forme d’une extension accessible depuis le menu de gauche. C’est un tchat depuis lequel vous pouvez demander un coup de main à Joule sur vos projets SAPUI5, CAP et ABAP Cloud. N’oubliez pas d’être courtois dans vos demandes, on ne sait pas jusqu’où l’IA ira à l’avenir…

Extension Joule de SAP Build Code

L’application d’exemple ayant été importée dans SAP Build Code, nous pouvons demander à l’assistante Joule de nous aider à compléter certains fichiers. Il peut lire les différents fichiers de l’application et, de manière générale, il est plutôt doué dans l’écriture de code.

Essayons le prompt suivant pour générer nos tests unitaires : “Écris-moi les fichiers de test unitaire pour le controller Home.controller.js”.

/ui5 create unit test file for #Home.controller.js write the test for every method in the controller.

Une syntaxe spécifique peut être utilisée pour cadrer Jouler :

• “/” au début de votre prompt permet de choisir
• ex : /fiori-gen-spec-app Generate an SAP Fiori elements application.
• # permet de lui indiquer un fichier précis à traiter à partir du contexte.
• La documentation est disponible ici.

La magie opère alors ! Et Joule propose un code QUnit avec quelques commentaires d’explication. Libre à vous d’accepter cette proposition ou de faire des ajustements avec des prompts supplémentaires. Lorsque vous acceptez, le code proposé par Joule est automatiquement ajouté dans un fichier de test dans le projet SAPUI5.

  Réponse contenant les tests unitaires générés par Joule

 En appuyant sur “Accept” le fichier est ajouté au projet

Vérifier le nommage du fichier pour moi, j’ai dû enlever le .test, ou précisez-le dans la prompt initiale.

Sans plus attendre, lançons les tests unitaires !

npm run unit-tests

Résultat : 4 tests passés sur 6. Ça n’est pas parfait, voyons quelles erreurs Joule a commise :

• Absence de mock pour la vue ou le composant : Joule appelle des méthodes comme this.getView() ou this.getOwnerComponent() sans s’assurer que ces objets ont été simulés dans l’environnement de test, ce qui entraîne des erreurs du type « Cannot read properties of undefined ».

• Certains noms de fonctions à tester était à renommer, ce qui est plutôt simple à corriger.
  
  
• Mauvaise gestion de l’environnement de test : L’absence de sandbox ou de nettoyage entre les tests peut entraîner des interférences, des effets de bord ou des tests non fiables.
  
• Structure de test incomplète : Il manque souvent un beforeEach pour initialiser le contrôleur ou un afterEach pour restaurer les stubs, ce qui compromet l’indépendance des tests.

Malgré ces quelques erreurs, la génération du fichier m’a tout de même fait gagner beaucoup de temps.

VS Code avec GitHub Copilot

Maintenant, on va tenter le même exercice dans VS code avec comme outil IA GitHub Copilot. Pensez-vous qu’il fera mieux que Joule ?!

Prérequis :

• Installer Visual Studio Code + l’extension “Remote Access for SAP Business Application Studio” ⇒ Access SAP Business Application Studio as a remote from Visual Studio Code
• Installer les extensions “GitHub Copilot” et “GitHub Copilot Chat”
• Importer l’application d’exemple “Manage Products”

Ces extensions ajoutent un tchat à l’interface Visual Studio Code pour dialoguer avec Copilot.

Copilot agit sur le fichier actuellement ouvert. On ouvre donc le contrôleur avec de donner le prompt à l’IA :

Write the unit test for this file.

Copilot va vous mettre des petits points sur les fichiers qu’il va modifier et si vous appuyez sur Keep  cela sera vraiment inclus au projet, vérifier ce que l’IA écrit, elle peut se tromper.

Pour Copilot les tests unitaires n’ont pas marché du premier coup :

• Oubli d’inclure sinon.js: sinon.js est une bibliothèque JavaScript utilisée pour créer des stubs, des mocks et des spies dans les tests unitaires. Ces outils sont essentiels pour isoler le code testé et simuler des comportements externes. Omettre sinon.js signifie que Copilot n’a pas correctement configuré l’environnement de test, ce qui aurait pu entraîner des erreurs ou des résultats de test incorrects.
• Erreur avec le test de vérification du model OData: Les applications SAPUI5 utilisent souvent des modèles OData pour interagir avec les services de données. Un test unitaire vérifiant le modèle OData doit s’assurer que les données sont correctement récupérées et manipulées. L’erreur de Copilot dans ce domaine suggère qu’il a mal interprété ou mal codé la façon de tester l’interaction avec le modèle OData. Cela pourrait inclure des erreurs dans la façon de simuler les réponses du service OData, de vérifier les données reçues, ou de tester les méthodes qui interagissent avec le modèle.

En résumé, les erreurs de Copilot montrent une difficulté à comprendre et à mettre en œuvre les spécificités des tests unitaires SAPUI5, notamment en ce qui concerne les dépendances externes (sinon.js) et l’interaction avec les modèles de données (OData). Cependant, avec des indications et des corrections supplémentaires, Copilot a finalement réussi à générer des tests unitaires corrects.

Copilot est aussi moins bon sur le framework SapUI5, il fait plus d’erreur avec les models.

Je n’ai pas essayé pour des tests complets comme OPA5 mais avoir un model IA entrainé pour ça comme Joule semble être plus efficace que Copilot, trop généraliste.

Conclusion

	Pour	Contre
Joule	Directement dans BAS les commandes à ajouter avant les prompts permettent un meilleur résultat.L’intégration dans BAS est très réussie.	L’interface utilisateur est moins bien que Copilot.Les possibilités semblent moindres même si on n’est qu’au début de Joule.Le cout de Joule est plus élevé, il est difficile d’estimer un prix moyen, mais vous pouvez le calculer sur SAP discovery center.
Copilot	L’interface dans VS Code est vraiment bien faite pour comprendre ce que l’IA fait avec les deux onglets Chat et Edit. La manipulation de Copilot est son gros point fort. Tous les outils associés à copilot que vous pouvez trouver dans VS code.	Le model est un peu trop généraliste en JavaScript et fait des erreurs sur SapUI5.

Copilot et Joule ne sont pas encore parfaits, ils font pour le moment beaucoup d’erreurs. Mais avec un petit temps de prise en main, ces IA peuvent vraiment vous faire gagner du temps sur des phases de code moins intéressantes.

Pour ma part, je préfère Copilot pour le moment. Mais il faut surveiller Joule, car elle vient d’arriver contrairement à Copilot qui a deux ans d’expérience et je ne doute qu’avec le temps et les ingénieurs SAP, elle deviendra très performante.

Et si vous souhaitez faire ces tests rapidement et de manière plus flexible, vous pouvez tester avec ChatGPT et Mistral en copier collant le code dans leur dans un navigateur à côté.

N’hésitez pas à tester et à partager vos expériences avec ces assistants IA  vous aurez peut-être des retours différents de moi, je débute encore dans SAP et ces tests sont vraiment simples, je vais essayer de les faire travailler sur des tâches plus complexes.