Rapport final et aperçu

Une exécution qui se termine, ce qui signifie qu’elle est arrivée au bout du travail par elle-même, transmet deux choses : un rapport final et un aperçu en direct de votre application. Les exécutions qui ont été mises en pause, arrêtées, interrompues ou qui ont dépassé leur budget ne le font pas.

Lorsqu’il y a une application à afficher, une notification l’indique. Elle affiche L’application est terminée, son rapport et son aperçu sont prêts lorsque l’aperçu est en cours d’exécution, et L’application est terminée, son rapport est prêt, et son aperçu démarre depuis l’onglet Rapport lorsqu’il ne l’est pas. Lorsque le rapport ne qualifie pas l’application de terminée, il affiche Une exécution s’est terminée, son rapport final est prêt. Le rapport et l’aperçu se trouvent dans l’onglet Report du Manager, côte à côte.

Le rapport final

Le rapport est construit à partir de l’historique de l’exécution, sans appel de modèle. Il ne relance jamais vos tests; il lit ce que le loop a fait.

• Ce qui a été construit : les fichiers créés ou modifiés par l’exécution, les cartes qu’elle a terminées, et le dernier résumé de chaque bubble avec ses propres mots.
• Comment l’exécuter : la commande de votre fichier README qui démarre l’application (npm run dev, npm start et ainsi de suite), avec l’étape d’installation en premier lorsque des dépendances manquent.
• Ce qui a été testé : la dernière commande de test exécutée par le loop, son code de sortie et le moment où elle a eu lieu.
• Ce qui manque : tout ce qui empêche l’exécution d’être comptée comme terminée, comme l’absence de fichier README, l’absence de script de test, des tests jamais exécutés, des tests en échec, des cartes toujours ouvertes, ou un aperçu qui a planté. Lorsqu’il ne manque rien, il affiche Rien que l’historique de l’exécution ne puisse voir.

Le rapport qualifie l’application de terminée lorsque :

1. le fichier README indique une seule commande pour l’exécuter,
2. la dernière exécution des tests a réussi,
3. aucun bubble ne s’est terminé sur ERROR, et
4. l’aperçu n’a pas planté.

Sous le verdict, le rapport indique également si l’application est présentable, d’après le dernier examen visuel de l’exécution : Présentable, l’examen visuel a réussi, …a échoué avec N blocages, ou non jugé lorsqu’aucun examen n’a eu lieu. Il est rapporté, et non compté : un loop sans interface n’a pas d’examen visuel, et un examen échoué met déjà fin à la passe du relecteur sur ERROR.

Avec un aperçu en cours d’exécution, le rapport prend également des captures d’écran de l’application. Les rapports sont enregistrés dans le projet, dans le dossier de l’application, au format JSON pour l’onglet et Markdown pour votre éditeur. Les 20 derniers sont conservés.

L’aperçu en direct

L’aperçu est le serveur de développement de votre application, un par tableau. Il est maintenu séparé des exécutions : la fin d’une exécution ne l’arrête pas, et une nouvelle exécution ne l’arrête pas non plus, de sorte qu’une application Vite continue de suivre les modifications du loop.

• Démarrez, redémarrez et arrêtez-le depuis l’onglet Report, et lisez son journal à cet endroit.
• À la fin d’une exécution, il ne démarre de lui-même que lorsque le tableau est en Full Auto et que la commande est autorisée. Sinon, appuyez sur Start preview.
• Un tableau qui isole les commandes dans des bacs à sable ne peut pas exécuter d’aperçu.
• Si le serveur s’arrête, l’onglet affiche son code de sortie et ses dernières lignes au lieu de devenir silencieusement vide.

L’examen visuel

Dans un loop qui construit une interface utilisateur, le relecteur effectue un examen visuel. Il ouvre l’application dans un vrai navigateur en 1280 × 800 et en 390 × 844 et vérifie chaque page.

• Ceux-ci font échouer l’examen immédiatement : une erreur HTTP, une superposition d’erreur du serveur de développement, une page blanche, une page plus large que sa fenêtre, une image cassée, du texte fictif tel que lorem ipsum ou TODO:, et des hôtes d’images de substitution.
• Si vous avez défini un modèle de vision (page Models, Helper models), il examine également les captures d’écran et les juge par rapport au fichier DESIGN.md du loop. Les problèmes de mise en page, les éléments fictifs et les images cassées qu’il marque comme bloquants font échouer l’examen, tandis que les notes de conception et de finition sont de simples conseils.
• Sans modèle de vision, les vérifications de la page décident seules, et le résultat indique clairement que personne n’a examiné les captures d’écran.

Paramètres › Agent browser propose Download Chromium, avec sa taille indiquée en premier. Une fois qu’il est présent, les exécutions sans fenêtre l’utilisent, sinon les agents utilisent une installation de Chrome ou d’Edge.