Aller au contenu principal

Introduction

Déclenchez des erreurs de test (404, 500) à la demande pour vérifier que vos pages d'erreur s'affichent correctement.

Plus d'informations sur l'interface utilisateur du module https://doc.oneentry.cloud/docs/category/system


🎯 Que fait ce module ?

Le module System vous permet de tester la gestion des pages d'erreur - simulez des erreurs 404 et 500 pour vérifier que vos pages d'erreur s'affichent correctement, vous aidant à garantir une gestion appropriée des erreurs avant que les utilisateurs ne rencontrent de réels problèmes.

Considérez-le comme votre outil de test d'erreurs - déclenchez des erreurs de test à la demande, vérifiez que les pages d'erreur s'affichent correctement et assurez-vous que votre logique de gestion des erreurs fonctionne comme prévu sans perturber la production.


📖 Explication Simple

Chaque application a besoin d'une gestion appropriée des erreurs :

  • 🔍 404 Non Trouvé - La page n'existe pas
  • 💥 500 Erreur Serveur - Échec interne du serveur
  • 🎨 Pages d'Erreur Personnalisées - Expérience d'erreur de marque
  • 🔄 Journalisation des Erreurs - Suivre les occurrences d'erreurs
  • 📊 Surveillance des Erreurs - Détecter les problèmes tôt
  • Test des Erreurs - Vérifier que les pages d'erreur fonctionnent

Problèmes :

  • 🔍 Pas de validation - Les pages d'erreur peuvent être cassées
  • 🎨 Mauvaise UX - Pages d'erreur par défaut peu attrayantes
  • 🔄 Pas de suivi - Ne sait pas quand les erreurs se produisent
  • 📊 Pas de surveillance - Ne peut pas détecter les problèmes

La solution System :

Avantages :

  • 🔍 Validé - Savoir que les pages d'erreur fonctionnent
  • 🎨 Meilleure UX - Pages d'erreur personnalisées de marque
  • 🔄 Suivi - Journaliser les occurrences d'erreurs
  • 📊 Surveillance - Détecter les problèmes tôt

✨ Concepts Clés

Qu'est-ce que le Module System ?

Le module System fournit des utilitaires de test :

  • Test des Erreurs - Simuler des erreurs 404/500
  • Validation des Pages d'Erreur - Vérifier que les pages d'erreur s'affichent
  • Vérification de la Gestion des Erreurs - Tester la logique d'erreur
  • Outil de Développement - Utiliser pendant le développement/test
  • Pas pour la Production - Ne pas utiliser dans le code en direct

Types d'Erreurs

Code d'ErreurNomQuand Cela Se ProduitCas d'Utilisation
404Non TrouvéLa ressource demandée n'existe pasPage non trouvée, produit manquant
500Erreur Serveur InterneUne erreur côté serveur s'est produiteÉchec de la base de données, erreur de code

Flux de Travail de Test

1. Develop error pages
(Custom 404 and 500 pages)

2. Implement error handling
(Try/catch, error boundaries)

3. Test with System module
(System.test404(), System.test500())

4. Verify error pages display
(Check UI, logging, tracking)

5. Deploy with confidence
(Know error handling works)

Pourquoi Utiliser le Module System ?

AvantageDescription
Validation des ErreursTester les pages d'erreur avant que les utilisateurs ne les voient
Outil de DéveloppementDéclencher des erreurs à la demande
Test de la Logique d'ErreurVérifier le code de gestion des erreurs
Pages d'Erreur PersonnaliséesAssurer une expérience d'erreur de marque
Détection PrécoceDétecter les problèmes avant la production

📋 Ce Que Vous Devez Savoir

Le Module System est Uniquement pour les Tests

Important : Utilisez le module System uniquement pendant le développement et les tests.

Pourquoi ?

  • Les erreurs de test ne doivent pas atteindre de vrais utilisateurs
  • Utiliser uniquement dans des environnements de développement/staging
  • Supprimer le code de test avant le déploiement en production

Meilleures Pratiques de Test des Erreurs

Testez les pages d'erreur pendant le développement

Pages d'Erreur Personnalisées

Créez des pages d'erreur personnalisées pour une meilleure UX

Journalisation et Surveillance des Erreurs

Implémentez le suivi des erreurs


💡 Notes Importantes

Outil de Développement Uniquement

Rappelez-vous : Le module System est pour les tests, pas pour la production.


Test des Erreurs vs Erreurs Réelles

Les erreurs du système sont simulées :

  • Les erreurs de test n'affectent pas les vrais utilisateurs
  • Utilisez-les pour vérifier la logique de gestion des erreurs
  • Supprimez-les avant le déploiement en production

Les erreurs réelles se produisent naturellement :

  • 404 réel : Page non trouvée
  • 500 réel : Échec du serveur
  • Gérez avec try/catch et des limites d'erreur

Pages d'Erreur Personnalisées Requises

Le module System ne déclenche que des erreurs - vous devez créer des pages d'erreur


📊 Tableau de Référence Rapide

MéthodeDescriptionLanceCas d'Utilisation
test404()Simuler une erreur 404 Non TrouvéErreur 404Tester la page d'erreur 404
test500()Simuler une Erreur Serveur 500Erreur 500Tester la page d'erreur 500

❓ Questions Fréquemment Posées (FAQ)

Quand devrais-je utiliser le module System ?

Utilisez le module System uniquement pendant le développement et les tests pour vérifier que vos pages d'erreur fonctionnent correctement. Ne l'utilisez jamais dans le code de production - c'est uniquement un outil de test pour valider la gestion des erreurs.


Comment tester mes pages d'erreur personnalisées ?

Appelez System.test404() ou System.test500() dans votre environnement de développement. Ces méthodes lancent des erreurs qui déclenchent votre logique de gestion des erreurs, vous permettant de vérifier que les pages d'erreur personnalisées s'affichent correctement.


Quelle est la différence entre test404() et test500() ?

test404() simule une erreur "Non Trouvé" (la ressource n'existe pas), tandis que test500() simule une "Erreur Serveur Interne" (échec côté serveur). Testez les deux pour vous assurer que tous les scénarios d'erreur sont gérés correctement.


Puis-je utiliser le module System en production ?

Non ! Le module System est strictement pour le développement et les tests. Supprimez tous les appels de test du module System avant de déployer en production. Utilisez une gestion des erreurs réelle (try/catch, limites d'erreur) pour les erreurs de production.


Comment créer des pages d'erreur personnalisées ?

Créez des composants de page d'erreur dédiés pour les erreurs 404 et 500 dans votre application. Utilisez des limites d'erreur (React) ou une gestion des erreurs équivalente dans votre framework pour capturer les erreurs et afficher ces pages personnalisées.


Dois-je journaliser les erreurs déclenchées par le module System ?

Oui, la journalisation des erreurs de test aide à vérifier que vos systèmes de suivi et de surveillance des erreurs fonctionnent correctement. Cependant, marquez-les clairement comme des erreurs de test pour éviter toute confusion avec de réels problèmes de production.


🎓 Meilleures Pratiques

  • Testez les pages d'erreur pendant le développement - Vérifiez qu'elles s'affichent correctement
  • Utilisez uniquement dans un environnement de test - Jamais en production
  • Implémentez des pages d'erreur personnalisées - Meilleure UX que les erreurs par défaut
  • Journalisez les erreurs pour le débogage - Suivez ce qui a mal tourné
  • Testez les limites d'erreur - Gestion des erreurs React/Vue
  • Vérifiez le suivi des erreurs - Assurez-vous que la surveillance fonctionne
  • Supprimez le code de test - Nettoyez avant le déploiement
  • Documentez la gestion des erreurs - Aidez l'équipe à comprendre le flux

Définition du module System

Le module System dans la plateforme OneEntry fournit des méthodes pour tester les redirections de pages d'erreur, permettant aux développeurs de s'assurer que leurs mécanismes de gestion des erreurs fonctionnent correctement. En utilisant la fonction defineOneEntry, vous pouvez créer un objet System pour accéder à ces fonctionnalités. Le module offre deux méthodes principales : test404 et test500. Les deux méthodes simulent des scénarios où l'utilisateur est redirigé vers une page d'erreur, spécifiquement les pages 404 (Non Trouvé) et 500 (Erreur Serveur Interne). Ces outils sont essentiels pour vérifier que les pages d'erreur du système sont correctement mises en œuvre et affichées aux utilisateurs lorsque cela est nécessaire.


const { System } = defineOneEntry(
"your-project-url", {
"token": "your-app-token"
}
);


🔗 Documentation Connexe