mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-27 23:08:16 +02:00
7767f1f947
28 nouvelles sections intégrées dans 12 fichiers knowledge (backend risques/patterns, frontend risques/patterns, workflow risques). Couvre rate limiting, RGPD, CSP Next.js, refresh token TOCTOU, catch-all Prisma, distinction 401/403, tests E2E Playwright, etc. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
174 lines
7.7 KiB
Markdown
174 lines
7.7 KiB
Markdown
---
|
|
title: Frontend — Risques & vigilance : Tests
|
|
domain: frontend
|
|
bucket: risques
|
|
tags: [tests, jest, react-native, ts-jest, coverage, facade]
|
|
applies_to: [analysis, implementation, review, debug]
|
|
severity: high
|
|
validated_on: 2026-04-07
|
|
source_projects: [app-alexandrie, app-template-resto, RL799_V2]
|
|
---
|
|
|
|
# Frontend — Risques & vigilance : Tests
|
|
|
|
> Extrait de la base de connaissance Lead_tech. Voir `knowledge/frontend/risques/README.md` pour l'index complet.
|
|
|
|
---
|
|
|
|
<a id="risque-jest-rn-config-node"></a>
|
|
## Jest React Native — config node bloque les composants `.tsx`
|
|
|
|
### Risques
|
|
|
|
- `SyntaxError: Cannot use import statement outside a module` lors de l'import d'un barrel `.ts` qui réexporte des `.tsx`
|
|
- Impossible d'importer des composants React Native dans les tests — JSX non transformé
|
|
|
|
### Symptômes
|
|
|
|
- Erreur de syntaxe inattendue au run des tests sur un fichier `.ts` qui importe un `.tsx`
|
|
- Les tests de tokens passent mais tout test touchant un composant échoue
|
|
|
|
### Bonnes pratiques / mitigations
|
|
|
|
- `transform: { '^.+\\.ts$': 'ts-jest' }` ne transforme que `.ts` — pas `.tsx`
|
|
- **Pattern recommandé** : tester la logique pure (tokens, valeurs de style) dans `.spec.ts`, le rendu visuel dans `.spec.tsx` avec une config séparée (`@testing-library/react-native` + `babel-jest`)
|
|
- Exporter le `StyleSheet` de chaque composant pour le tester sans JSX (voir pattern dédié dans `10_frontend_patterns_valides.md`)
|
|
- Contexte technique : React Native / Jest / ts-jest — app-alexandrie 19-03-2026
|
|
|
|
---
|
|
|
|
<a id="risque-faux-test-negatif"></a>
|
|
## Faux test négatif — tester le helper au lieu de tester l'exclusion
|
|
|
|
### Risques
|
|
|
|
- Un test nommé "X n'utilise pas Y" qui appelle Y en interne est un test normal mal documenté, pas un test d'exclusion
|
|
- Donne une fausse confiance sur le comportement par défaut du helper
|
|
|
|
### Symptômes
|
|
|
|
- Test intitulé "sans fallback, la valeur EN vide n'est pas remplacée" mais qui appelle le helper avec fallback activé
|
|
|
|
### Bonnes pratiques / mitigations
|
|
|
|
- Un vrai test négatif vérifie que X n'importe pas Y, ou que le comportement par défaut empêche l'effet indésirable
|
|
- Pour un helper à fallback optionnel : tester explicitement le cas `fallbackToFr=false` (défaut) avec une valeur vide
|
|
|
|
- Contexte technique : TypeScript / Jest — app-template-resto 17-03-2026
|
|
|
|
---
|
|
|
|
<a id="risque-helpers-copies-tests"></a>
|
|
## Helpers copiés localement dans les tests (faux positif permanent)
|
|
|
|
### Risques
|
|
|
|
- La logique réellement exécutée en production peut diverger du helper copié dans le test sans casser aucun test.
|
|
- Un refactor du module source ne casse pas le test — la couverture est illusoire.
|
|
|
|
### Symptômes
|
|
|
|
- Fonctions utilitaires redéfinies dans `*.spec.ts` plutôt qu'importées depuis le module de production
|
|
- Tests verts malgré une régression dans le code source
|
|
|
|
### Bonnes pratiques / mitigations
|
|
|
|
- Les tests doivent importer le module réellement utilisé par l'écran/composant, jamais dupliquer la logique.
|
|
- Si la logique est partagée entre écran et test, l'extraire dans un utilitaire partagé (single source of truth).
|
|
- **Checklist review** : aucune fonction de production recopiée dans `*.spec.ts`.
|
|
|
|
- Contexte technique : TypeScript / Jest — 30-03-2026
|
|
|
|
---
|
|
|
|
<a id="risque-test-ecran-indirect"></a>
|
|
## Test d'écran indirect — logique UI validée via helper adjacent non relié au flux
|
|
|
|
### Risques
|
|
|
|
- Le test reste vert même si la logique de décision UI dans le screen diverge du helper testé.
|
|
- Un changement d'implémentation de l'écran ne casse aucun test.
|
|
|
|
### Symptômes
|
|
|
|
- `*.spec.ts` d'un écran qui n'importe pas le composant/écran mais seulement un helper utilitaire adjacent
|
|
- Couverture affichée OK mais comportement réel de l'écran non testé
|
|
|
|
### Bonnes pratiques / mitigations
|
|
|
|
- La logique de décision UI doit être soit testée via rendu composant (`@testing-library/react-native`), soit extraite dans un module dédié importé par le screen ET par le test (single source of truth).
|
|
- **Règle** : un test qui n'importe pas le composant écran ni son module de logique ne peut pas valider le comportement de l'écran.
|
|
|
|
- Contexte technique : React Native / Jest — 30-03-2026
|
|
|
|
---
|
|
|
|
<a id="risque-test-facade-flux-reel"></a>
|
|
## Test de façade — helpers adjacents validés à la place du flux réel
|
|
|
|
### Risques
|
|
|
|
- Une tâche d'intégration (conversion, persistance, atomicité, contrat UI) est clôturée alors que les tests ne valident que des helpers purs (chemins, labels, sanitization).
|
|
- Le pipeline réel, la persistance DB et les transitions UI ne sont jamais exercés.
|
|
|
|
### Symptômes
|
|
|
|
- Tests `*.spec.ts` créés uniquement sur des fonctions utilitaires pures pour une story qui promet un pipeline
|
|
- La tâche est cochée ✅ mais aucun test n'appelle le module de traitement de production
|
|
|
|
### Bonnes pratiques / mitigations
|
|
|
|
- Si une tâche promet conversion, statut DB, atomicité ou contrat UI/public : le test doit appeler le module de production correspondant ou un seam injecté unique.
|
|
- **Règle** : un test qui ne vérifie que des helpers adjacents ne peut pas clôturer une tâche d'intégration.
|
|
|
|
- Contexte technique : TypeScript / Jest — app-template-resto 31-03-2026
|
|
|
|
---
|
|
|
|
<a id="risque-tests-presence-textuelle-faux-gardefou"></a>
|
|
## Tests de présence textuelle = faux garde-fou de non-régression
|
|
|
|
### Risques
|
|
|
|
- Des tests basés uniquement sur `content.includes(...)` valident du texte statique tout en laissant passer des régressions réelles sur auth/API et comportements UI
|
|
- Les AC fonctionnels sont déclarés validés alors que le flux réel (autosave, submit, transitions d'état) n'est pas exercé
|
|
|
|
### Symptômes
|
|
|
|
- Tests qui lisent le fichier `.vue` et assertent uniquement des chaînes (`includes`) sans exécuter le composant ni ses interactions
|
|
- Story cochée malgré des régressions fonctionnelles invisibles aux tests verts
|
|
- Services API et guards d'accès validés par des assertions textuelles au lieu de tests comportementaux
|
|
|
|
### Bonnes pratiques / mitigations
|
|
|
|
- Exiger au moins un test comportemental par flux critique (montage composant + interaction + assertion d'effet)
|
|
- Reléguer les tests textuels au rôle de smoke structurel non bloquant
|
|
- Pour les services API et guards d'accès : exiger un test exécutant réellement la fonction (mock fetch/session/router) et validant statuts d'erreur + contrat d'appel
|
|
- Pour les templates/checklists critiques : ne pas se limiter à la présence de mots-clés, valider la structure attendue (sections obligatoires, champs non vides, format minimal)
|
|
- **Règle** : si un test vérifie un *comportement* (ex: "le menu se ferme après clic"), il doit monter le composant, pas chercher une string dans le source
|
|
|
|
- Contexte technique : Vue 3 / node:test — RL799_V2 02-04-2026
|
|
|
|
---
|
|
|
|
<a id="risque-catch-false-test-skip-e2e"></a>
|
|
## Anti-pattern : `.catch(() => false)` + `test.skip` dans les tests E2E
|
|
|
|
### Risques
|
|
|
|
- Le pattern `await locator.isVisible().catch(() => false)` suivi de `test.skip(true, ...)` masque les erreurs réelles (sélecteur cassé, timeout, changement de structure) derrière un skip silencieux
|
|
- Un AC peut rester perpétuellement non testé sans qu'aucun rapport ne le signale comme problème
|
|
|
|
### Symptômes
|
|
|
|
- Tests skippés en permanence dans les rapports CI
|
|
- AC marqués `[x]` dans la story mais jamais réellement validés
|
|
|
|
### Bonnes pratiques / mitigations
|
|
|
|
- Pour vérifier si un élément optionnel est présent (données dépendantes du seed), utiliser `await locator.count()` qui retourne 0 sans lancer d'exception, puis `test.skip` uniquement si count === 0
|
|
- Réserver `.catch()` aux cas où une exception est réellement attendue et documentée
|
|
- **Signal review** : `.catch(() => false)` suivi de `test.skip` dans un test E2E
|
|
|
|
- Contexte technique : Playwright / E2E — RL799_V2 08-04-2026
|