Compétences javascript-testing-patterns
🧪

javascript-testing-patterns

Sûr

Maîtriser les modèles de test JavaScript

Également disponible depuis: wshobson

Écrire des tests est difficile. Cette compétence fournit des modèles éprouvés et des exemples pour les tests unitaires, d'intégration et de bout en bout utilisant Jest, Vitest et Testing Library afin que vous puissiez créer rapidement des suites de tests fiables.

Prend en charge: Claude Codex Code(CC)
🥉 74 Bronze
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

Activez et commencez à utiliser

Tester

Utilisation de "javascript-testing-patterns". Write unit tests for an add function that takes two numbers and returns their sum

Résultat attendu:

  • ```typescript
  • import { describe, it, expect } from 'vitest';
  • import { add } from './calculator';
  •  
  • describe('add', () => {
  • it('should add two positive numbers', () => {
  • expect(add(2, 3)).toBe(5);
  • });
  •  
  • it('should add negative numbers', () => {
  • expect(add(-2, -3)).toBe(-5);
  • });
  •  
  • it('should handle zero', () => {
  • expect(add(0, 5)).toBe(5);
  • });
  • });
  • ```

Utilisation de "javascript-testing-patterns". Create a test for a user form component that validates email and submits data

Résultat attendu:

  • ```typescript
  • import { render, screen, fireEvent } from '@testing-library/react';
  • import { describe, it, expect, vi } from 'vitest';
  • import { UserForm } from './UserForm';
  •  
  • describe('UserForm', () => {
  • it('should show validation error for invalid email', () => {
  • render(<UserForm onSubmit={vi.fn()} />);
  • fireEvent.change(screen.getByTestId('email-input'), {
  • target: { value: 'invalid-email' }
  • });
  • fireEvent.click(screen.getByRole('button', { name: 'Submit' }));
  • expect(screen.getByText('Invalid email')).toBeInTheDocument();
  • });
  •  
  • it('should call onSubmit with form data', () => {
  • const onSubmit = vi.fn();
  • render(<UserForm onSubmit={onSubmit} />);
  • fireEvent.change(screen.getByTestId('name-input'), {
  • target: { value: 'John Doe' }
  • });
  • fireEvent.change(screen.getByTestId('email-input'), {
  • target: { value: 'john@example.com' }
  • });
  • fireEvent.click(screen.getByRole('button', { name: 'Submit' }));
  • expect(onSubmit).toHaveBeenCalledWith({
  • name: 'John Doe',
  • email: 'john@example.com'
  • });
  • });
  • });
  • ```

Audit de sécurité

Sûr
v1 • 2/25/2026

All 145 static findings are false positives. The detected patterns exist only in code examples within markdown documentation files, not in executable code. The skill provides educational content about testing patterns with code samples demonstrating legitimate testing practices including mock setup, API testing, email service testing, and database integration testing. No executable code, no security risks.

2
Fichiers analysés
1,063
Lignes analysées
0
résultats
1
Total des audits
Aucun problème de sécurité trouvé
Audité par: claude

Score de qualité

38
Architecture
100
Maintenabilité
87
Contenu
50
Communauté
100
Sécurité
91
Conformité aux spécifications

Ce que vous pouvez construire

Configuration de test pour un nouveau projet

Les développeurs qui démarrent un nouveau projet JavaScript/TypeScript et qui doivent établir l'infrastructure de testfrom scratch avec une configuration de framework appropriée, une structure de répertoire et une intégration CI/CD.

Ajouter des tests à une base de code existante

Les équipes maintenant des applications legacy ou non testées qui ont besoin d'introduire progressivement des tests pour les fonctions, les API et les composants existants sans casser les fonctionnalités existantes.

Améliorer la couverture de tests

Les développeurs cherchant à augmenter la couverture de code et améliorer la qualité des tests en apprenant des modèles de simulation avancés, des fabriques de fixtures et des stratégies de test d'intégration.

Essayez ces prompts

Test unitaire de base 
Écrire des tests unitaires pour une fonction qui [décrire ce que fait la fonction]. Inclure des tests pour les cas de succès et la gestion des erreurs.
Test de composant avec Testing Library 
Créer des tests React Testing Library pour un composant qui [décrire le comportement du composant]. Tester les interactions utilisateur, les soumissions de formulaires et les états d'erreur.
Test d'intégration d'API 
Écrire des tests d'intégration pour un endpoint d'API REST qui [décrire la fonctionnalité de l'endpoint]. Inclure la configuration de la base de données, l'authentification et le nettoyage en utilisant supertest.
Simuler les dépendances externes 
Créer des tests pour [service/classe] qui simulent les dépendances externes, y compris [liste des dépendances]. Utiliser l'injection de dépendances et les modèles vi.mock.

Bonnes pratiques

  • Suivre le modèle Arrange-Act-Assert (AAA) dans chaque test pour une structure claire et une lisibilité
  • Tester les comportements et les interactions utilisateur plutôt que les détails d'implémentation pour rendre les tests résilients au refactoring
  • Utiliser les hooks beforeEach et afterEach pour la configuration et le nettoyage afin de garder les tests isolés et éviter la pollution

Éviter

  • Tester les détails d'implémentation comme les appels de fonctions internes ou l'état du composant au lieu du comportement observable
  • Écrire des tests fragiles qui cassent quand le code est refactorisé mais que le comportement reste inchangé
  • Créer des configurations de test trop complexes avec trop de simulations qui rendent les tests difficiles à comprendre et maintenir

Foire aux questions

Dois-je utiliser Jest ou Vitest ?
Vitest est plus rapide et fonctionne mieux avec les projets Vite. Jest est plus mature et a une adoption plus large. Choisissez Vitest si vous utilisez Vite, sinon Jest est un choix sûr.
Comment tester du code qui utilise des API externes ?
Simuler les appels d'API externes en utilisant vi.mock() ou l'injection de dépendances. Cela garde les tests rapides, fiables et indépendants des services externes.
Quelle couverture de tests dois-je viser ?
Viser 80% de couverture comme objectif général. Se concentrer sur la couverture de la logique métier critique et des chemins d'erreur plutôt que de viser 100% de couverture.
Dois-je tester les méthodes privées ?
Non. Tester uniquement le comportement public. Si les méthodes privées ont besoin de tests, considérer les refactoriser en unités séparées et testables.
Comment gérer les tests de base de données ?
Utiliser une base de données de test séparée et nettoyer les données entre les tests en utilisant beforeEach. Envisager d'utiliser des transactions pour un rollback plus rapide au lieu de tronquer les tables.
Quelle est la différence entre les tests unitaires et d'intégration ?
Les tests unitaires isolent les fonctions ou classes individuelles. Les tests d'intégration vérifient que plusieurs composants fonctionnent ensemble, y compris les bases de données et les API.

Détails du développeur

Auteur

sickn33

Licence

MIT

Dépôt

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/javascript-testing-patterns

Réf

main

Structure de fichiers

📁 resources/

📄 implementation-playbook.md

📄 SKILL.md