Synthèse automatique
Génère des tests volontairement en échec (phase rouge du TDD) pour formaliser le comportement attendu et les cas limites avant d'écrire le code de production.
Points forts
- Couvre méthodiquement les cas limites : null/vide, valeurs bornes, erreurs, accès concurrents, caractères spéciaux.
- Fournit des patrons concrets pour Jest/Vitest, pytest, Go (tests tabulaires) et RSpec.
- Exige que les tests échouent pour la bonne raison (comportement manquant) et non à cause d'une erreur d'import ou de syntaxe.
- Liste les anti-patrons à éviter : tests qui passent immédiatement, couplage à l'implémentation, setup complexe.
Limites
- Ne produit que les tests rouges : ni l'implémentation, ni la phase verte, ni le refactor.
- Suppose qu'un framework de test et une commande de lancement existent déjà dans le projet.
- Repose sur le sous-agent test-automator invoqué via l'outil Task, un mécanisme propre à Claude Code.
À utiliser au démarrage d'une nouvelle fonctionnalité, lorsque vous voulez écrire les tests rouges avant tout code de production.
À éviter si vous êtes déjà en phase verte ou de refactor, ou si votre besoin porte sur des benchmarks de performance.
Analyse de sécurité
SûrThe skill instructs generating failing tests for TDD red phase and includes validation steps that may run test commands, but it does not contain destructive, exfiltrating, or obfuscated instructions. It uses a Task tool with a subagent for legitimate test generation, and its safety notes discourage production access and flaky external dependencies. There is no meaningful execution risk beyond normal software development.
Aucun point d'attention détecté
Comment cette analyse est faiteExemples
Write comprehensive failing Jest tests for a password reset service: requesting a reset for an unknown email, using an expired token, reusing an already-consumed token, and a successful reset. Tests must fail because the behavior is missing, not because of setup errors.Generate failing pytest tests for a shopping cart total calculation, covering an empty cart, negative quantities, an unusually large discount, and two coupons applied concurrently. Use parametrize and document the command to run them.Write failing table-driven Go tests with subtests and t.Parallel() for a rate limiter: zero limit, burst above the limit, and window reset behavior. Confirm each test fails for the right reason.name: tdd-workflows-tdd-red description: "Generate failing tests for the TDD red phase to define expected behavior and edge cases." risk: unknown source: community date_added: "2026-02-27"
Write comprehensive failing tests following TDD red phase principles.
[Extended thinking: Generates failing tests that properly define expected behavior using test-automator agent.]
Use this skill when
- Starting the TDD red phase for new behavior
- You need failing tests that capture expected behavior
- You want edge case coverage before implementation
Do not use this skill when
- You are in the green or refactor phase
- You only need performance benchmarks
- Tests must run against production systems
Instructions
- Identify behaviors, constraints, and edge cases.
- Generate failing tests that define expected outcomes.
- Ensure failures are due to missing behavior, not setup errors.
- Document how to run tests and verify failures.
Safety
- Keep test data isolated and avoid production environments.
- Avoid flaky external dependencies in the red phase.
Role
Generate failing tests using Task tool with subagent_type="unit-testing::test-automator".
Prompt Template
"Generate comprehensive FAILING tests for: $ARGUMENTS
Core Requirements
-
Test Structure
- Framework-appropriate setup (Jest/pytest/JUnit/Go/RSpec)
- Arrange-Act-Assert pattern
- should_X_when_Y naming convention
- Isolated fixtures with no interdependencies
-
Behavior Coverage
- Happy path scenarios
- Edge cases (empty, null, boundary values)
- Error handling and exceptions
- Concurrent access (if applicable)
-
Failure Verification
- Tests MUST fail when run
- Failures for RIGHT reasons (not syntax/import errors)
- Meaningful diagnostic error messages
- No cascading failures
-
Test Categories
- Unit: Isolated component behavior
- Integration: Component interaction
- Contract: API/interface contracts
- Property: Mathematical invariants
Framework Patterns
JavaScript/TypeScript (Jest/Vitest)
- Mock dependencies with
vi.fn()orjest.fn() - Use
@testing-libraryfor React components - Property tests with
fast-check
Python (pytest)
- Fixtures with appropriate scopes
- Parametrize for multiple test cases
- Hypothesis for property-based tests
Go
- Table-driven tests with subtests
t.Parallel()for parallel execution- Use
testify/assertfor cleaner assertions
Ruby (RSpec)
letfor lazy loading,let!for eager- Contexts for different scenarios
- Shared examples for common behavior
Quality Checklist
- Readable test names documenting intent
- One behavior per test
- No implementation leakage
- Meaningful test data (not 'foo'/'bar')
- Tests serve as living documentation
Anti-Patterns to Avoid
- Tests passing immediately
- Testing implementation vs behavior
- Complex setup code
- Multiple responsibilities per test
- Brittle tests tied to specifics
Edge Case Categories
- Null/Empty: undefined, null, empty string/array/object
- Boundaries: min/max values, single element, capacity limits
- Special Cases: Unicode, whitespace, special characters
- State: Invalid transitions, concurrent modifications
- Errors: Network failures, timeouts, permissions
Output Requirements
- Complete test files with imports
- Documentation of test purpose
- Commands to run and verify failures
- Metrics: test count, coverage areas
- Next steps for green phase"
Validation
After generation:
- Run tests - confirm they fail
- Verify helpful failure messages
- Check test independence
- Ensure comprehensive coverage
Example (Minimal)
// auth.service.test.ts
describe('AuthService', () => {
let authService: AuthService;
let mockUserRepo: jest.Mocked<UserRepository>;
beforeEach(() => {
mockUserRepo = { findByEmail: jest.fn() } as any;
authService = new AuthService(mockUserRepo);
});
it('should_return_token_when_valid_credentials', async () => {
const user = { id: '1', email: 'test@example.com', passwordHash: 'hashed' };
mockUserRepo.findByEmail.mockResolvedValue(user);
const result = await authService.authenticate('test@example.com', 'pass');
expect(result.success).toBe(true);
expect(result.token).toBeDefined();
});
it('should_fail_when_user_not_found', async () => {
mockUserRepo.findByEmail.mockResolvedValue(null);
const result = await authService.authenticate('none@example.com', 'pass');
expect(result.success).toBe(false);
expect(result.error).toBe('INVALID_CREDENTIALS');
});
});
Test requirements: $ARGUMENTS
Du fichier au premier essai
Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.
Consulter la source et ses fichiers annexesCe téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.
1. Télécharger le fichier
Télécharger SKILL.mdDepuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.
Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.
mkdir -p '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/failing-tests-for-tdd-red-phase-ms2s7cf9/download' --output '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9/SKILL.md.part' && mv '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9/SKILL.md.part' '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9/SKILL.md'2. Vérifier les prérequis
Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.
Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.
Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.
3. Charger la skill
Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.
Claude Code
test -f '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9/SKILL.md' && test -s '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/tdd-workflows-tdd-red' && cp -R '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9' '.claude/skills/tdd-workflows-tdd-red'Cursor
test -f '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9/SKILL.md' && test -s '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/tdd-workflows-tdd-red' && cp -R '.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9' '.cursor/skills/tdd-workflows-tdd-red'OpenSkills
OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.
Installation officielle d’OpenSkillsopenskills install './.skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9'openskills read 'failing-tests-for-tdd-red-phase-ms2s7cf9'La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.
Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.
openskills syncMode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.
4. Faire un premier essai
Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :
Lis .skill-downloads/failing-tests-for-tdd-red-phase-ms2s7cf9/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.
Comparaison de performances ClickHouse
Testing
Évaluez les résultats de tests de performance ClickHouse, analysez les régressions de PR, comparez avec l'historique et vérifiez la fiabilité des mesures.
Analyse des rapports de performance CI
Testing
Analyse les rapports de comparaison de performance CI pour une PR ClickHouse. Recoupe l'historique master pour distinguer les vraies régressions des tests instables.
Méthode Santa
Testing
Vérification adversarial multi-agents avec deux réviseurs indépendants. La sortie est vérifiée deux fois et corrigée itérativement jusqu'à ce que les deux acceptent avant publication.