Le point de départ, en toute honnêteté
Si vous ne savez pas lire le code, vous ne pouvez pas le relire, et il est temps d'arrêter de culpabiliser. L'alternative n'est pas la relecture, c'est la vérification du comportement. C'est de toute façon ce que feront vos utilisateurs, et cela révèle une catégorie de problèmes que la lecture laisserait passer.
Où se trouvent généralement les bugs du code Lovable
Les applications générées échouent dans un ordre prévisible. Commencez par ces points.
| L'enregistrement semble réussi, mais ne l'est pas | Un formulaire affiche un message de succès, puis l'entrée a disparu après un rafraîchissement. Rechargez toujours la page avant de croire à une sauvegarde. |
| États vides et états d'erreur | Le scénario nominal a été construit et présenté. Les cas sans résultat et les requêtes en échec, souvent pas. Essayez sans aucune donnée, puis avec une saisie volontairement erronée. |
| Le deuxième utilisateur | Tout fonctionne pour le compte qui a créé l'application. Les permissions, la propriété des données et la visibilité sont les premières choses qui cassent pour les autres. Connectez-vous avec un second compte avant de montrer l'application à qui que ce soit. |
Une vérification qui tient dans la durée
Vérifier à la main convient pour un projet de week-end, mais ne tient plus dès que vous enchaînez les prompts. Chaque nouvelle instruction peut défaire silencieusement quelque chose qui fonctionnait hier, et une passe manuelle se raccourcit à chaque fois que vous la refaites.
Ce qu'il vous faut, ce sont des vérifications consignées et exécutées automatiquement, décrites en langage courant plutôt qu'en code de test. La configuration met cette capacité entre les mains de l'agent, pour que la vérification se fasse en même temps que la construction.
Tout cela est également disponible dans le tableau de bord TestSprite, généralement la meilleure voie si le terminal n'est pas votre environnement de travail. Les détails du CLI se trouvent dans le dépôt CLI.
Trois vérifications à avoir dès le premier jour
Créez un compte, puis reconnectez-vous. C'est là que cassent le plus d'applications générées, et c'est la première chose que fait un vrai utilisateur.
Créez quelque chose, rechargez, vérifiez que c'est toujours là. Cette seule vérification attrape la défaillance la plus fréquente et la plus embarrassante.
Faites la chose pour laquelle votre application existe, depuis un compte tout neuf. Si cela fonctionne pour un inconnu, vous tenez quelque chose.
Comment décrire un bug pour que le correctif tombe juste
Quand quelque chose ne va pas, le réflexe est de dire « c'est cassé ». Cela donne très peu de matière à l'agent, et vous récupérerez une modification qui corrige quelque chose à côté.
Trois phrases font bien mieux, et aucune ne demande de vocabulaire technique. Ce que vous avez fait, dans l'ordre. Ce que vous attendiez. Ce qui s'est passé à la place. « J'ai rempli le formulaire et appuyé sur enregistrer, je m'attendais à voir le nouvel élément dans la liste, la liste est restée vide jusqu'à ce que je recharge » est un vrai bon rapport de bug, et il pointe directement le défaut.
Ces trois mêmes phrases constituent aussi la vérification que vous conservez. Une fois écrites, elles peuvent être rejouées après chaque modification future : c'est ainsi que vous empêchez le même problème de revenir.
Dans quel ordre vérifier
Il existe un enchaînement qui trouve les problèmes plus vite que de cliquer au hasard, et il prend une dizaine de minutes.
Commencez déconnecté et créez un compte en tant qu'utilisateur tout neuf, car c'est le parcours que vous avez personnellement le moins emprunté. Faites ensuite la seule chose pour laquelle votre application existe, jusqu'au bout, et rechargez la page avant d'y croire. Recommencez ensuite en faisant tout de travers : laissez un champ obligatoire vide, mettez du texte là où un nombre est attendu, téléversez quelque chose d'absurde. Puis supprimez quelque chose et vérifiez que c'est bien supprimé et non simplement masqué.
Chacune de ces quatre étapes prend une ou deux minutes et correspond à une famille de défaillances des applications générées. Les faire dans cet ordre compte, car une inscription cassée rend tout le reste intestable, et il est courant de passer une heure sur une fonctionnalité que personne ne peut atteindre.
Quand vient le moment de la partager
Avant qu'une application n'arrive quelque part de sérieux, faites tourner les vérifications automatiquement à chaque modification, plutôt que quand vous y pensez. Deux façons de procéder :
Connectez le dépôt depuis le tableau de bord et les exécutions démarrent à partir du déploiement que vous produisez déjà, ou bien ajoutez plutôt une étape à votre propre workflow.
Comment TestSprite vérifie à votre place
Vous décrivez en langage courant ce qui devrait être vrai, et TestSprite se charge des clics. Pas de code de test, pas de framework, pas de terminal nécessaire : créez un projet dans le tableau de bord, pointez-le vers votre application et décrivez à quoi ressemble une version qui fonctionne.
Les quatre familles de défaillances de cette page sont exactement ce qu'il couvre. Il crée un compte, crée quelque chose puis recharge pour confirmer que l'enregistrement a tenu, soumet une saisie invalide pour vérifier que l'application le signale, et rejoue le même parcours en tant que second utilisateur pour attraper les hypothèses de permissions intégrées à votre propre session.
Ce qui compte quand vous enchaînez les prompts, c'est que les vérifications restent. Chaque modification est vérifiée par rapport à tout ce qui fonctionnait avant elle, ce qui met fin à la boucle où corriger une chose en casse discrètement une autre.
Faut-il savoir coder pour cela ?
Non. Les vérifications sont décrites en langage courant et exécutées sur l'application via son interface, exactement comme une personne l'utiliserait.
Pourquoi mon application fonctionne-t-elle pour moi et pas pour les autres ?
En général, à cause des permissions ou de la propriété des données. Le compte qui a créé l'application dispose d'enregistrements et d'accès qu'un nouveau compte n'a pas. Tester en tant que second utilisateur le révèle immédiatement.
Faut-il tester avant ou après de nouveaux prompts ?
Les deux, et le second moment compte davantage. C'est une vérification qui existait avant votre dernière instruction qui vous dira si cette instruction a cassé quelque chose.
Et si le correctif casse systématiquement autre chose ?
C'est le signe qu'il faut faire tourner les vérifications en continu plutôt qu'à la fin. Chaque modification est vérifiée par rapport à tout ce qui fonctionnait avant elle.
Est-ce réservé à Lovable ?
Non. Les mêmes défaillances apparaissent dans tout ce qui est généré rapidement, quel qu'en soit l'outil. Les utilisateurs de Lovable les rencontrent plus tôt parce qu'ils mettent en production plus vite.
Vous ne pouvez pas relire le code. Vous pouvez vérifier le comportement.
La plupart des bugs du code Lovable sont des enregistrements qui ne persistent pas, des états vides absents et des fonctionnalités qui ne marchent que pour le compte qui les a créées. Vérifiez ces trois points en premier, puis rendez les vérifications automatiques avant de partager l'application.