Skip to main content

Vue d’ensemble

Kit’Asso utilise Vitest comme test runner et React Testing Library pour tester les composants. L’approche privilégie les tests qui reflètent l’utilisation réelle par les utilisateurs. Stack de test :
  • Vitest 3.2.4 (test runner rapide, Vite-native)
  • @testing-library/react (tests composants)
  • @testing-library/jest-dom (matchers DOM)
  • @testing-library/user-event (interactions utilisateur)
  • jsdom (environnement DOM simulé)
Coverage actuel : ~55% (objectif: 80%)

Configuration

Vitest Config

Fichier : vitest.config.ts

Setup File

Fichier : src/test/setup.ts

Tester l’API Layer

Mock du client Nhost

Le pattern de base pour tester les modules API consiste à mocker nhost.graphql.request() : Fichier : src/api/__tests__/tools.spec.ts
Convention Hasura : Les mutations d’update utilisent _set (avec underscore). Vos mocks doivent refléter cette convention pour être réalistes.

Tester les Hooks

Test d’un custom hook

Fichier : src/hooks/__tests__/useFavorites.spec.ts

Tester les Composants

Test d’un composant simple

Fichier : src/components/__tests__/Button.spec.tsx

Test d’un composant complexe

Fichier : src/components/__tests__/ToolCard.spec.tsx

Mock Factories

Créer des données de test

Fichier : src/test/mockFactories.ts

Mock du client Nhost (helper réutilisable)

Usage dans les tests :

Test Utilities

Render personnalisé avec providers

Fichier : src/test/testUtils.tsx
Usage :

Commandes de test

Scripts disponibles


Coverage

Générer le rapport

Output :
Ouvrir dans le navigateur :

Objectifs de coverage


Bonnes pratiques

✅ À faire

Tester le comportement, pas l’implémentation
Utiliser des queries accessibles
Mock au bon niveau (API layer, pas les hooks)

❌ À éviter

Ne pas tester les détails d’implémentation
Ne pas ignorer les erreurs de console

Ressources

API Layer

Tests des modules API (GraphQL)

Custom Hooks

Tests des hooks

Components

Tests des composants UI

Conventions

Standards de qualité de code