Objectif et périmètre
Créez des payloads mock reproductibles, générez des valeurs conformes aux formats, repérez les noms de champs ambigus et contrôlez un serveur mock temporaire avant partage.
Ce guide transforme le périmètre annoncé en résultat vérifiable. Conservez la source, les résultats intermédiaires et les décisions afin que la personne suivante comprenne ce qui a été contrôlé et pourquoi.
Préparer les éléments et décider
Préparez les formes de requête et de réponse, les champs obligatoires, les valeurs d'énumération et quelques cas valides et invalides.
N'utilisez que des valeurs inventées ; retirez les identifiants réels, jetons d'accès, fiches client et autres données personnelles avant de saisir la fixture.
Définissez l'environnement de test, la durée du mock, le responsable de la fixture et les éléments de preuve à conserver pour l'acceptation.
Décision: Le champ vient-il d'un profil de données ou d'un motif strict ?. Choisissez Test Data Faker Builder pour les enregistrements structurés et les profils reproductibles. Choisissez Regex to String Generator lorsqu'un identifiant, un code postal ou une version doit respecter un motif précis ; conservez le motif et les exemples dans les notes de revue.
Décision: La fixture est-elle prête à être exposée comme endpoint mock ?. Ne publiez pas juste après la génération. Résolvez les collisions de noms, examinez les valeurs limites, supprimez les contenus sensibles et confirmez que la définition cible une surface isolée hors production.
Réaliser le workflow
1. Construire la fixture structurée
Configurez la structure, les champs obligatoires, les catégories contrôlées et un nombre reproductible d'exemples dans Test Data Faker Builder. Séparez une réponse normale, un résultat vide et un échec de validation volontaire au lieu de les mélanger dans un même payload. Utiliser test-data-faker-builder.
2. Compléter les valeurs au format strict
Générez les identifiants et autres chaînes contraintes à partir des expressions régulières relues. Vérifiez les correspondances et les quasi-correspondances qui doivent échouer afin de couvrir les limites sans confondre syntaxe et validité métier. Utiliser regex-to-string-generator.
3. Revoir les noms et les risques de collision
Soumettez le JSON ou le schema assemblé au détecteur de conflits de noms. Renommez les abréviations ambiguës, les champs visuellement proches et les préfixes concurrents avant que le client ou la documentation ne les adopte. Utiliser mock-data-naming-conflict-detector.
4. Exposer le mock relu sans élargir le risque
Créez la définition temporaire uniquement après les contrôles précédents. Vérifiez routes, méthodes, modèles de réponse, expiration et hypothèses d'accès ; utilisez des données inventées et notez que le mock ne teste ni comportement, ni latence, ni autorisation, ni persistance d'un service réel. Utiliser api-mock-server.
Vérifier le résultat avant la remise
- La fixture contient les champs requis et des valeurs représentatives reproductibles, avec des cas valides, vides et volontairement invalides séparés.
- Les valeurs soumises à un format respectent leur motif déclaré et la revue des noms ne laisse aucune ambiguïté visuelle ni collision de préfixe non résolue.
- La définition mock n'expose que des données inventées et non sensibles sur la surface temporaire prévue ; la revue précise qu'elle ne remplace pas les tests d'un service réel.
Questions fréquentes
- Ce workflow teste-t-il une API réelle ? Non. Il prépare et expose une fixture mock temporaire. Le comportement réel, l'authentification, la persistance, la latence et la compatibilité d'intégration exigent des tests de contrat ou d'intégration séparés, notamment le workflow API Contract Testing associé.
- Quelles données peut-on mettre dans une fixture ? Utilisez des noms, identifiants, adresses, jetons et états de compte inventés. Ne copiez jamais de secrets de production, de jetons d'accès, d'exports clients ou d'autres données personnelles dans la fixture ou sa définition.
- Pourquoi générer des correspondances et des quasi-correspondances regex ? Les correspondances montrent la forme attendue par le client ; les quasi-correspondances testent le rejet et les limites. Une correspondance regex ne prouve pas qu'une valeur est unique, autorisée ou valable pour le métier.
- Quand une fixture peut-elle être partagée ? Après avoir consigné et fait accepter les champs, les limites, la revue des noms, l'absence de données sensibles, la configuration du mock et le périmètre hors production par le responsable.