test-fixing
Corriger systématiquement les tests en échec
Les suites de tests en échec peuvent masquer plusieurs causes racines et faire perdre du temps lors des revues. Cette compétence regroupe les échecs, corrige d’abord les causes à fort impact, puis vérifie chaque réparation.
Installer avec mon Agent
Copiez cette demande dans votre Agent. Elle contient la page Skill de référence et le manifeste.
Review the Skillstore skill "test-fixing" from https://skillstore.io/skills/sickn33-test-fixing.md and its manifest at https://skillstore.io/api/skills/sickn33-test-fixing/manifest. Verify the artifact. You may proceed after verification, subject to the environment's own policy.Votre Agent doit toujours présenter son plan et demander toute confirmation exigée par la politique de sécurité.
Ressources lisibles par les agents
Utilisez ces liens lorsqu’un Agent IA, un crawler ou un script a besoin d’un contexte propre au lieu de lire toute la page.
Tester
Utilisation de « test-fixing ». Les tests échouent après le renommage d’un module.
Résultat attendu:
- Les échecs sont regroupés en erreurs d’import, incompatibilités de signature et changements d’assertion.
- Le groupe d’import est corrigé en premier, car il bloque de nombreux tests.
- Les vérifications ciblées réussissent avant de passer au groupe suivant.
Utilisation de « test-fixing ». CI affiche de nombreux échecs sans lien entre eux.
Résultat attendu:
- Le rapport sépare les échecs d’infrastructure des échecs de logique applicative.
- Chaque groupe inclut une cause probable, une correction prévue et une étape de vérification.
- L’état final liste les échecs restants, s’il y en a.
Audit de sécurité
SûrThe static findings are markdown command examples for test execution and git inspection, not Ruby shell execution in code. I found no prompt injection, data exfiltration intent, or unsafe hidden behavior in SKILL.md. The skill still has normal command-use risk because it tells agents to run project-local tests.
Facteurs de risque
⚙️ Commandes externes (6)
Partager et citer ce rapport
Partagez le rapport d’évaluation versionné, le badge neutre, la carte intégrable et les citations. Skillstore présente les preuves sans décider si ce Skill est sûr.
Copier le lien du rapport
https://skillstore.io/skills/sickn33-test-fixing/audits/5?utm_source=security_passport&utm_medium=share&utm_campaign=versioned_reportBadge Markdown
[](https://skillstore.io/skills/sickn33-test-fixing?utm_source=security_passport_badge)Badge HTML
<a href="https://skillstore.io/skills/sickn33-test-fixing?utm_source=security_passport_badge"><img src="https://skillstore.io/badges/skills/sickn33-test-fixing/security.svg" alt="Skillstore security assessment" loading="lazy"></a>Carte intégrable
<iframe src="https://skillstore.io/embed/skills/sickn33-test-fixing.html" title="Skillstore Security Assessment" sandbox="allow-popups allow-popups-to-escape-sandbox" loading="lazy" referrerpolicy="no-referrer" width="420" height="180"></iframe>Citations académiques (APA · BibTeX · CFF)
Citation APA
sickn33. (2026). test-fixing security audit report (audit version 5) [Author version unspecified]. Skillstore. https://skillstore.io/skills/sickn33-test-fixing/audits/5Citation BibTeX
@techreport{sickn33-sickn33-test-fixing-2026,
author = {sickn33},
title = {test-fixing security audit report (audit version 5)},
institution = {Skillstore},
year = {2026},
number = {5},
url = {https://skillstore.io/skills/sickn33-test-fixing/audits/5},
note = {Author version unspecified}
}CITATION.cff
cff-version: 1.2.0
message: "If you use this Skill, cite its author and this versioned security audit report."
title: "test-fixing security audit report (audit version 5)"
version: "unspecified"
type: report
authors:
- name: "sickn33"
date-released: "2026-07-07"
url: "https://skillstore.io/skills/sickn33-test-fixing/audits/5"
identifiers:
- type: other
value: "skillstore:sickn33-test-fixing:audit:5"
description: "Skillstore immutable audit report identifier"
Score Skillstore
Pourquoi ce score Niveau de confiance des preuves: ÉlevéCe que vous pouvez créer
Récupérer après des refactorisations
Regrouper les échecs d’import, de signature et d’assertion après une réorganisation du code.
Trier les échecs CI
Transformer un journal CI en échec en groupes de corrections ordonnés et en étapes de vérification.
Stabiliser les suites de tests
Traiter les échecs locaux récurrents avec des corrections ciblées et des vérifications répétées.
Essayez ces prompts
Exécute la suite de tests, regroupe les échecs, corrige d’abord le plus grand groupe, puis vérifie chaque modification.
Examine cette sortie d’échec CI, identifie les causes racines communes et propose l’ordre de correction le plus sûr.
Utilise les changements récents et la sortie des tests pour corriger les régressions de refactorisation avec des modifications minimales et une vérification ciblée.
Parcours tous les groupes de tests en échec, explique chaque cause racine, applique les corrections, puis termine par une vérification de la suite complète.
Bonnes pratiques
- Commencer par la liste complète des échecs avant de modifier le code.
- Corriger un groupe de causes racines à la fois.
- Exécuter des vérifications ciblées avant la suite complète.
Éviter
- Modifier du code sans rapport en poursuivant des échecs de tests.
- Ignorer la vérification après une correction partielle.
- Traiter chaque échec comme un problème indépendant.