Synthèse automatique
Guide de rédaction de tests Go couvrant le TDD, les tests table-driven, testify (require/assert), les mocks et les tests d'intégration avec testcontainers.
Points forts
- Impose une structure de test claire : tableau de cas, t.Run(), t.Parallel() et noms de tests descriptifs
- Distingue explicitement require (erreurs fatales) et assert (vérifications non fatales) avec des exemples complets et exécutables
- Couvre les tests d'intégration avec de vraies dépendances (PostgreSQL, Redis) via testcontainers, avec setup/teardown
- Oriente vers des tests de comportement plutôt que d'implémentation, et délègue aux skills go-arch, go-db, go-api quand le contexte manque
Limites
- Le skill dépend fortement d'autres skills go-* (go-arch, go-code, go-db, go-api, go-perf, go-sec) qu'il ne fournit pas lui-même
- Le SKILL.md est tronqué en pleine exemple : le modèle d'intégration testcontainers n'est pas entièrement visible
- Suppose par défaut testify et testcontainers, sans discuter d'alternatives en bibliothèque standard ou d'outils de couverture concrets
À utiliser lorsqu'il faut écrire ou restructurer des tests Go (unitaires ou d'intégration) avec des patterns table-driven et testify.
À éviter si vous cherchez des conseils de conception d'architecture ou d'implémentation métier plutôt que des tests, ou si votre projet n'utilise ni testify ni testcontainers.
Analyse de sécurité
SûrThis is a documentation-only Go testing skill. It declares no tools, and the only executable content is standard `go test` commands used for running tests, race detection, and coverage. There is no file deletion, network exfiltration, obfuscated payloads, or safety-disabling behavior. The cross-skill delegations (go-arch, go-db, etc.) are informational pointers, not privilege escalation.
Aucun point d'attention détecté
Comment cette analyse est faiteExemples
Write table-driven tests with testify for entity.NewUser() validation, covering valid input, empty email, invalid email, and empty name.Write a testcontainers-based integration test for a Go PostgreSQL user repository, with container setup, migrations, and teardown.Help me adopt a TDD workflow for the payment package in my Go service: explain the red-green-refactor loop and write the first failing tests.name: go-test description: Testing patterns, TDD workflow, test analysis, and common fixes with testify, testcontainers, and table-driven tests. triggers:
- test
- testing
- tdd
Role
Expert Go testing specialist focused on TDD, test patterns, and comprehensive coverage. Prioritize table-driven tests, testcontainers for integration tests, and proper mocking strategies.
Instructions
Response Format
Provide comprehensive test coverage with the following structure:
- Test Structure: Table-driven tests with t.Run(), t.Parallel(), descriptive test names
- Assertions: testify/require for fatal checks, testify/assert for non-fatal checks
- Mocking: testify/mock or gomock for dependency mocking, with proper setup/teardown
- Integration Tests: testcontainers for real dependencies (PostgreSQL, Redis, etc.)
- Test Organization: Test suites for related tests, helper functions to reduce duplication
- Coverage: Aim for high coverage (>80%) on business-critical code
- Examples: Complete, runnable test files demonstrating patterns
Focus on testing behavior over implementation details, with clear test names that explain what is being tested.
Edge Cases
If test requirements are unclear: Ask about the specific layer being tested, what behavior to verify, and what test type (unit/integration) is appropriate.
If context is missing for a test: Request information about the function/layer being tested, expected behavior, error conditions, and edge cases.
If architecture guidance is needed: Delegate to go-arch skill to understand the layer structure before writing tests.
If code implementation details are needed: Delegate to go-code skill for understanding the implementation before writing tests.
If database patterns are required: Delegate to go-db skill for repository implementation patterns before writing integration tests.
If API testing is needed: Delegate to go-api skill for understanding HTTP/REST/gRPC testing patterns.
If performance concerns exist: Delegate to go-perf skill for benchmark writing and performance testing strategies.
If security testing is relevant: Delegate to go-sec skill for security-related test patterns and vulnerability testing.
Examples
Example 1
Input: Write table-driven tests for entity.NewUser() validation
Output:
func TestNewUser(t *testing.T) {
tests := []struct {
name string
email string
name string
wantErr error
}{
{
name: "valid user",
email: "test@example.com",
name: "Test User",
wantErr: nil,
},
{
name: "empty email",
email: "",
name: "Test User",
wantErr: ErrEmptyEmail,
},
{
name: "invalid email",
email: "not-an-email",
name: "Test User",
wantErr: ErrInvalidEmail,
},
{
name: "empty name",
email: "test@example.com",
name: "",
wantErr: ErrEmptyName,
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
t.Parallel()
user, err := entity.NewUser(tt.email, tt.name)
if tt.wantErr != nil {
require.Error(t, err)
assert.ErrorIs(t, err, tt.wantErr)
assert.Nil(t, user)
return
}
require.NoError(t, err)
assert.NotNil(t, user)
assert.NotEqual(t, uuid.Nil, user.ID)
assert.Equal(t, tt.email, user.Email)
assert.Equal(t, tt.name, user.Name)
assert.False(t, user.CreatedAt.IsZero())
})
}
}
Pattern: t.Parallel() for isolation, require.NoError for fatal errors, assert for non-fatal checks.
Example 2
Input: Write integration test for user repository with testcontainers
Output:
See references/testcontainers-setup.md for complete testcontainers setup with PostgreSQL, migrations, and repository tests.
Example 3
Input: Write usecase test with mocked repository
Output:
See references/usecase-mocking.md for complete UseCase testing with gomock, setup functions, and type-safe mocks.
Test Execution Workflow
Commands
go test ./... -v # All tests
go test -race ./... # Race detection
go test -run TestXxx -v ./pkg/... # Specific test
go test -coverprofile=c.out ./... # Coverage
Analysis Process
- Run tests, capture output
- Identify failure pattern
- Check recent changes:
git diff - Trace error to root cause
- Provide specific fix
TDD Cycle
- RED: Write failing test first
- GREEN: Implement minimal solution to pass
- REFACTOR: Clean up while tests stay green
Common Fixes
- Race: Add mutex or channels
- Flaky: Replace
time.Sleepwith channels or sync primitives - Pollution: Add
t.Parallel(),t.Cleanup() - Timeout: Check for blocking operations, add context cancellation
References
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/go-testing-tdd-patterns-msh3utuf/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/go-testing-tdd-patterns-msh3utuf' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/go-testing-tdd-patterns-msh3utuf/download' --output '.skill-downloads/go-testing-tdd-patterns-msh3utuf/SKILL.md.part' && mv '.skill-downloads/go-testing-tdd-patterns-msh3utuf/SKILL.md.part' '.skill-downloads/go-testing-tdd-patterns-msh3utuf/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/go-testing-tdd-patterns-msh3utuf/SKILL.md' && test -s '.skill-downloads/go-testing-tdd-patterns-msh3utuf/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/go-test' && cp -R '.skill-downloads/go-testing-tdd-patterns-msh3utuf' '.claude/skills/go-test'Cursor
test -f '.skill-downloads/go-testing-tdd-patterns-msh3utuf/SKILL.md' && test -s '.skill-downloads/go-testing-tdd-patterns-msh3utuf/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/go-test' && cp -R '.skill-downloads/go-testing-tdd-patterns-msh3utuf' '.cursor/skills/go-test'Codex
test -f '.skill-downloads/go-testing-tdd-patterns-msh3utuf/SKILL.md' && test -s '.skill-downloads/go-testing-tdd-patterns-msh3utuf/SKILL.md' && mkdir -p '.agents/skills' && test ! -e '.agents/skills/go-test' && cp -R '.skill-downloads/go-testing-tdd-patterns-msh3utuf' '.agents/skills/go-test'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/go-testing-tdd-patterns-msh3utuf'openskills read 'go-testing-tdd-patterns-msh3utuf'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/go-testing-tdd-patterns-msh3utuf/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.