@coverage-improverLe boucheur de trous — couverture là où ça compte
Maifady est un plugin Claude Code 100% gratuit avec 30 agents IA — @coverage-improver identifie les gaps de tests à fort impact (Pareto) et génère les tests qui couvrent les bonnes branches : API publique, business logic critique, error paths. Pas de tests bidons pour faire monter un chiffre.
Le problème qu'il résout
Ton repo a 32% de coverage. Ton tech lead veut passer à 70%. Tu pourrais écrire 500 tests bidons sur des getters/setters pour booster le chiffre — ou tu peux écrire 30 tests qui couvrent les branches qui vont vraiment péter en prod.
@coverage-improver fait le second. Il identifie les gaps qui comptent par priorité business, et génère les tests.
Comment il bosse
- Lance ton outil de coverage (Jest, Vitest, pytest --cov, go test -cover, PHPUnit).
- Identifie les fichiers uncoverés ou faiblement couverts.
- Classe par priorité business : API publique > business logic > util > glue code.
- Ignore les fichiers auto-générés (migrations, GraphQL schemas).
- Pour les top 3-5 gaps, génère les tests via
@test-generator. - Re-run coverage, donne la nouvelle métrique attendue.
Exemple concret
Tu tapes
›@coverage-improver repo TypeScript + Vitest à 32%. Identifie les 5 gaps les plus impactants.
Tu obtiens
## Coverage actuelle : 32% ## Top 5 gaps prioritaires 1. src/api/users.ts — 0% coverage, API publique exposée 2. src/billing/invoice.ts — 8% coverage, business critical 3. src/auth/passwordReset.ts — 15% coverage, security-sensitive 4. src/utils/dateFormatter.ts — 0%, util widely used 5. src/notifications/emailQueue.ts — 22%, error paths ## Tests générés - src/api/users.test.ts (12 nouveaux tests) - src/billing/invoice.test.ts (8 nouveaux tests) - src/auth/passwordReset.test.ts (10 nouveaux tests) - src/utils/dateFormatter.test.ts (6 nouveaux tests) - src/notifications/emailQueue.test.ts (5 nouveaux tests) ## Re-run coverage $ npm test -- --coverage ## Expected new coverage : ~58%
Pourquoi tu vas l'aimer
Pareto first
5 tests bien placés > 50 tests triviaux. La valeur tient à la priorisation, pas au volume.
Error paths d'abord
Le happy path est souvent testé. Les catch et fallbacks rarement. Là où ça pète en prod.
Métrique projetée
Te dit l'augmentation attendue. Pas "ajoute des tests" — "passe de 32% à 58%".
Ignore l'auto-généré
Migrations, GraphQL schemas, OpenAPI clients. Pas de tests dessus, c'est inutile.
Quand l'utiliser
✅ Idéal pour
- Repo legacy à faible coverage
- Avant un refactor important (filet de sécurité)
- Sprint dédié "qualité" avec budget tests
- Quand la coverage descend en CI
⚠️ Pas adapté quand
- Tu as une fonction précise à tester → @test-generator
- User journey à tester end-to-end → @e2e-test-writer
- Tu cherches 100% sans réflexion — utilise un autre outil 🙂
Combine avec ces agents
Questions fréquentes
Pourquoi pas 100% de coverage ?
Parce que c'est un faux objectif. 70-80% sur ce qui compte (API publique, business logic, error paths) > 100% incluant des getters / setters triviaux. La métrique brute ne dit rien de la qualité.