# blop Blop est un agent QA qui écrit des tests navigateur dans votre dépôt, les exécute en CI, regroupe les échecs récurrents et peut ouvrir des pull requests pour corriger les tests défaillants. - Findings24: - Site web: - Tarifs: Freemium - Catégories: Assistant Code IA, Outils Dev IA, Assistants de tests IA ## Qu'est-ce que blop ? Blop est un agent QA destiné aux équipes qui souhaitent conserver leurs tests navigateur sous forme de code dans leur dépôt, plutôt que dans le tableau de bord d’un fournisseur. Vous décrivez un parcours en français courant, et l’agent le parcourt dans un véritable navigateur pour créer et maintenir un test dont vous restez propriétaire. Blop exécute ces tests dans votre CI, publie des résultats structurés dans la pull request qui les a déclenchés et regroupe les échecs récurrents afin de faciliter le suivi des problèmes répétitifs. Lorsqu’une modification de l’interface fait échouer un test, Blop peut ouvrir une pull request proposant une correction et une étape de vérification, pour que le flux de travail reste centré sur des diffs faciles à examiner. ## Que peut faire blop ? ### Tests sous forme de code, guidés par l’intention Décrivez un parcours en français courant et blop le transforme en test \`.blop.ts\` qui exprime l’intention plutôt que de se résumer à un script de sélecteurs. Le test reste dans votre dépôt et peut être examiné comme tout autre code. ### Exécution dans un navigateur avec Playwright L’agent pilote un véritable navigateur pour parcourir le flux avec Playwright ; le résultat du test reflète ainsi un parcours réel plutôt qu’un état masqué dans un tableau de bord. ### Exécution native dans la CI Blop exécute les tests dans votre CI à l’aide de vos runners GitHub Actions existants, pour s’intégrer au pipeline que vous utilisez déjà. ### Regroupement des échecs Les échecs récurrents sont regroupés afin qu’un même sélecteur cassé ou une même modification de l’interface n’apparaisse pas sous la forme de dizaines de lignes distinctes au fil des exécutions. ### Pull requests de correction rédigées par l’agent Lorsqu’un échec s’y prête, l’agent peut ouvrir une pull request qui corrige le test et vérifie qu’il réussit avant la revue. La correction automatique est proposée en accès anticipé. ### Surveillance synthétique N’importe quel test peut aussi être planifié comme sonde récurrente en production, avec la disponibilité, la durée p95 et l’achèvement du parcours comme indicateurs. ## Cas d'utilisation ### Transformer les parcours produit en code Les équipes peuvent décrire en français courant un parcours de paiement, d’inscription ou autre, puis obtenir un test navigateur qui peut être versionné et examiné en parallèle des modifications du produit. ### Trier les échecs récurrents Lorsque le même problème de sélecteur ou la même régression de l’interface réapparaît, le regroupement des échecs rassemble les résultats similaires en un seul problème à examiner. ### Corriger les tests au moyen de pull requests Si une modification de l’interface fait échouer un test, l’agent peut examiner la trace, la sortie de la console et le diff, puis ouvrir une pull request avec une correction ciblée et une exécution de vérification. ### S’intégrer à un flux CI existant Les équipes qui utilisent déjà GitHub Actions peuvent exécuter les tests sur leurs runners CI actuels, sans héberger un environnement d’exécution distinct. ### Surveiller les parcours critiques N’importe quel test peut être planifié comme sonde récurrente en production afin de surveiller la disponibilité, l’achèvement du parcours et la durée p95 des flux utilisateur importants. ## Questions fréquentes ### Où sont stockés mes tests ? Les tests sont stockés dans votre dépôt sous forme de fichiers \`.blop.ts\`. Ils sont versionnés, révisables et modifiables ou supprimables par votre équipe. ### Y a-t-il un essai gratuit ? Oui. Chaque formule commence par un essai gratuit de 7 jours, qui donne accès à toutes les fonctionnalités de la formule choisie. Aucune carte bancaire n’est requise pour commencer. ### Dois-je héberger mes propres runners ? Blop s’exécute sur vos runners GitHub Actions existants, qu’ils soient dans le cloud ou auto-hébergés. Le plan de contrôle n’exécute pas lui-même les tests. ### Fonctionne-t-il uniquement avec Playwright ? Aujourd’hui, Blop privilégie Playwright. Le résultat est défini par un contrat versionné, et le site indique que des adaptateurs pour d’autres frameworks sont prévus. ### Comment l’agent corrige-t-il les tests en échec ? Lorsqu’une exécution échoue, l’agent examine l’échec, la trace et le diff, puis peut ouvrir une pull request avec une correction ciblée et une exécution de vérification. La correction automatique est en accès anticipé et aucune modification n’est fusionnée sans approbation. ## Informations rapides - **Catégorie**: Outil pour développeurs - **Usage principal**: Tests navigateur et automatisation QA - **Mode d’exécution**: S’exécute dans votre CI avec des runners GitHub Actions - **Format des tests**: Fichiers \`.blop.ts\` dans votre dépôt - **Framework**: Playwright en priorité - **Tarification**: Formules par utilisateur avec un essai gratuit de 7 jours