_Assistant_Lead_Tech/knowledge/frontend/risques/tests.md

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-03-31 source_projects: [app-alexandrie, app-template-resto]

Frontend — Risques & vigilance : Tests

Extrait de la base de connaissance Lead_tech. Voir knowledge/frontend/risques/README.md pour l'index complet.

---

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

---

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

---

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

---

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

---

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