For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /fr/docs/web/testing.md (or send Accept: text/markdown).
Stratégie de test
Comprenez ce que valident les tests déterministes, navigateur, base de données et fournisseur.
Configuration et paramètres
Avant toute étape, lisez Avant de commencer et Principes de base du terminal. Ces instructions supposent que vous avez ouvert le monorepo supastack complet dans VS Code ; sa racine package.json marque la racine du référentiel. Dans les commandes pnpm, un package d'espace de travail est une application ou un dossier de code partagé ; dans le produit, un espace de travail est le conteneur de données et la limite de sécurité d'une équipe. corepack pnpm --filter ... sélectionne un package dans le monorepo tandis que les commandes sont exécutées à partir de sa racine. Si vous avez ouvert uniquement un dossier mobile ou de bureau synchronisé, il ne contient pas le backend Web, la configuration Docker ou les scripts racine : exécutez le backend à partir de ce monorepo ou d'un serveur hébergé accessible et utilisez les propres scripts du dossier de plateforme. Une variable d'environnement est un paramètre nommé stocké dans un fichier .env local ou dans votre tableau de bord d'hébergement ; redémarrez l'application concernée après l'avoir modifiée et conservez les secrets du serveur en dehors des valeurs NEXT_PUBLIC_ et EXPO_PUBLIC_.
1. Ouvrez le package.json racine du référentiel pour voir les commandes de vérification.
2. À partir de ce dossier racine, exécutez corepack pnpm test pour les tests unitaires automatisés, puis corepack pnpm --filter @supastack/web typecheck pour les vérifications Web TypeScript.
3. Pour connaître le comportement du navigateur, démarrez l'application Web et exécutez le corepack pnpm test:e2e. Attendu : chaque commande rapporte son propre résultat ; un test unitaire ne prouve pas qu'une véritable base de données, un fournisseur de paiement, un service de messagerie ou un téléphone fonctionne.
La suite de tests par défaut utilise des adaptateurs locaux ou factices déterministes. Les tests navigateur couvrent les interactions ; l’acceptation de la base et les essais réels des fournisseurs sont des étapes séparées. Exécutez les vérifications correspondant au comportement modifié avant d’élargir la portée.
corepack pnpm test
corepack pnpm check
corepack pnpm build
corepack pnpm test:e2e
corepack pnpm test:e2e:productionCommandes à copier
Suivez les commentaires pour voir dans quel dossier une commande s'exécute. Si deux terminaux sont étiquetés, ouvrez deux fenêtres de terminal et laissez la première commande s'exécuter pendant que vous utilisez la seconde.
corepack pnpm test
corepack pnpm --filter @supastack/web typecheck
corepack pnpm test:e2eProcessus d’implémentation
Pour un changement de comportement, écrivez d’abord un test d’acceptation qui échoue. Associez un accès réussi aux refus pour un utilisateur anonyme et un autre espace de travail. Dans les formulaires et parcours de tâches, vérifiez aussi le chargement, les erreurs et la reprise, pas uniquement le succès attendu.
Une réponse navigateur interceptée prouve que l’interface réagit à ce scénario de test. Elle ne prouve ni la persistance de l’authentification, ni le traitement d’un paiement, ni la livraison par un fournisseur, ni un callback sur appareil physique.
Vérification et dépannage
Si un test de base de données indique qu'il a été ignoré, configurez sa base de données de test isolée avant de signaler la couverture de la base de données. Si un onglet Web se trouve sur le port 3001, il s'agit du serveur apps/docs distinct ; l'application Web du kit démarre sur le port 3000. Si Playwright échoue lors de sa première exécution sous Windows, laissez l'installation du navigateur se terminer et réexécutez la commande défaillante ; ne désactivez jamais la sécurité à l’échelle du système pour la contourner.
Si un test soumis à la base est ignoré, configurez sa base de test isolée avant d’affirmer que cette étape a réussi. Si un runner navigateur affiche des assertions réussies mais reste bloqué pendant son arrêt, rapportez les deux faits ; un processus bloqué ne constitue pas une commande entièrement réussie.
Sous Windows, une exécution initiale du navigateur peut expirer pendant que Defender analyse les navigateurs ou dépendances Playwright nouvellement installés. Laissez l'installation se terminer, réexécutez la suite ayant échoué avec le corepack pnpm test:e2e ou le corepack pnpm test:e2e:production et inspectez sa trace et l'historique de protection Defender en cas d'échec à nouveau. Laissez la protection à l’échelle du système activée.
La suite de navigateurs locaux possède le port 3100 et refuse de réutiliser un processus qui y écoute déjà. Définissez PLAYWRIGHT_PORT sur un port libre avant le corepack pnpm test:e2e si une autre application possède 3100 ; cela empêche les tests de cibler silencieusement un autre projet.