Générez automatiquement la couverture de tests du nouveau code

Zero scanne les PR mergées à la recherche de fichiers non testés, écrit des tests en suivant vos conventions, et ouvre une PR pour que vous commenciez chaque journée avec une meilleure couverture.

Zero se connecte à :

Ce que Zero livre

Générez automatiquement la couverture de tests du nouveau code — sample output from Zero — screenshot 1

Quel est le problème

C'est mardi matin. La CI est rouge - la couverture est passée de 82% à 79% pendant la nuit parce que quelqu'un a mergé une nouvelle fonctionnalité sans aucun test. Encore. Vous pourriez tout arrêter, lire leur code et écrire les tests vous-même. Ou vous pourriez confier ça à Zero chaque matin à 4h, pour qu'en vous installant, une PR de tests soit déjà en attente de revue.

Comment Zero le corrige

Étape 1 : Connectez vos outils

GitHub

Requis

GitHub - accès en lecture pour scanner les PR mergées et les fichiers modifiés. Accès en écriture pour ouvrir des pull requests avec les tests générés.

Connecter

Slack

Requis

Slack - publie une synthèse des tests générés et des résultats de CI sur votre canal d'équipe.

Connecter

Linear

Optionnel

useCases.content.auto-test-coverage.integrations.2.description

Connecter

Étape 2 : Demandez à Zero

@Zero vérifie toutes les PR mergées des dernières 24 heures dans vm0-ai/vm0. Pour chaque fichier modifié qui n'a pas de fichier de test correspondant, écris des tests d'intégration en suivant les patterns de test du projet. Ouvre une seule PR avec tous les nouveaux tests.

essayer

Zero scanne les PR mergées à la recherche de fichiers non couverts

Zero interroge GitHub pour les pull requests récemment mergées, liste chaque fichier modifié, et le croise avec votre répertoire de tests. Les fichiers qui n'ont pas de fichier de test correspondant sont signalés pour couverture.

Zero écrit des tests en suivant les conventions de votre projet

Zero lit le fichier source, comprend l'interface du composant ou de la fonction, vérifie vos patterns de test existants (framework, imports, helpers, style d'assertion), et écrit des tests qui s'intègrent harmonieusement - même structure, mêmes patterns, même niveau de qualité.

Zero ouvre une PR et publie une synthèse

Tous les tests générés atterrissent dans une seule pull request avec une description claire de ce qui est couvert. Zero publie un tableau récapitulatif dans Slack indiquant quels fichiers ont reçu des tests et combien. La CI tourne automatiquement, et Zero relance avec le résultat.

Étape 3 : Allez plus loin

Relire et merger la PR de tests

Vérifiez les tests générés et mergez s'ils vous conviennent.

@Zero quel est le statut CI de la PR de tests #10153 ?

essayer

Exclure les fichiers générés ou de config

Dites à Zero quels fichiers ignorer pour qu'il se concentre sur une couverture pertinente.

@Zero lors de la couverture automatique des tests, ignore tous les fichiers dans generated/, les *.d.ts et les fichiers de config

essayer

En faire une routine

Planifiez une génération de tests quotidienne pour que la couverture ne baisse plus jamais.

@Zero chaque jour à 4h, scanne les changements mergés sans tests, écris-les et ouvre une PR

essayer

Conseils pour de meilleurs résultats

●Soyez explicite sur votre framework de test et vos patterns - "utilise vitest avec @testing-library/react, suis le pattern arrange-act-assert" produit un bien meilleur résultat.

●Lancez-le pendant la nuit pour que la PR de tests soit prête à être relue quand l'équipe arrive. 4h est un bon paramètre par défaut - il tourne après les merges tardifs de la nuit.

●Enchaînez avec tech-debt-scan pour une santé de code complète : la dette technique attrape les anti-patterns, auto-test-coverage attrape les lacunes, ensemble ils gardent votre base de code propre.