Benchmarking de Générateurs d'Instances JSON Schema

Les générateurs d'instances JSON Schema adoptent une approche dite optimiste : ils combinent des fragments de schémas en supposant leur compatibilité, puis s'appuient éventuellement sur un validateur externe pour éliminer les instances invalides. Ce projet évalue expérimentalement les limites de cette stratégie sur quatre corpus industriels réels via la rétro-ingénierie de trois bibliothèques open source.

Librairies analysées

Trois générateurs ont été étudiés selon leur approche de génération et leur couverture du standard JSON Schema Draft-7 :

• json-schema-faker (JavaScript/Node.js) - approche optimiste avec support de faker.js et chance.js pour la génération de données synthétiques réalistes ; générateur principal de l'étude.
• json-everything (C#/.NET) - générateur aléatoire pur, sans dépendances de fake data ; couverture partielle du standard.
• json-data-generator (JavaScript) - génération template-driven ; couverture plus limitée des mots-clés de validation.

Pipeline expérimental

Le pipeline se déroule en trois étapes successives pour chaque couple (schéma, générateur) :

1. Génération - le générateur produit N instances à partir du schéma cible.
2. Validation - chaque instance est soumise au validateur Python jschon (implémentation complète de Draft-7).
3. Classification des erreurs - les instances invalides sont catégorisées selon le mot-clé JSON Schema en cause pour identifier les lacunes systématiques.

Corpus de schémas

Quatre datasets industriels ont été utilisés, couvrant des domaines applicatifs variés :

Résultats de validité

Taux de validité des instances générées par json-schema-faker (générateur principal) sur les quatre datasets :

Les deux autres générateurs présentent des taux inférieurs : json-everything atteint ~72 % sur Kubernetes, et json-data-generator échoue à interpréter plusieurs mots-clés de validation avancés (notamment if/then/else et dependencies).

Quatre limitations identifiées dans json-schema-faker

1. Nombre de propriétés hors contraintes

Quand un schéma spécifie simultanément minProperties et maxProperties, le générateur ignore maxProperties lors de la fusion de sous-schémas, produisant des objets trop fournis :

// schéma : { "minProperties": 2, "maxProperties": 3, "properties": {...5 props...} }
// jsf génère un objet avec 5 propriétés → invalide (> maxProperties)

2. Conjonction not + affirmatif

La gestion de not est locale : le générateur ne propage pas la contrainte négative lors de la résolution des sous-schémas frères, ce qui peut produire des valeurs interdites par not :

// schéma : { "not": { "type": "string" }, "type": ["string", "null"] }
// jsf génère parfois une string → invalide (satisfait le not interdit)

3. oneOf sans résolution de conflit

Pour oneOf, jsf sélectionne aléatoirement une branche sans vérifier l'exclusivité - si l'instance générée satisfait plusieurs branches simultanément, la validation échoue :

// schéma : { "oneOf": [{ "minimum": 5 }, { "maximum": 10 }] }
// valeur 7 satisfait les deux branches → invalide pour oneOf

4. required avec propriétés absentes du schéma

Quand required liste des noms absents de properties, le générateur n'ajoute pas ces propriétés à l'objet construit, violant la contrainte d'obligatoriété :

// schéma : { "properties": { "a": {} }, "required": ["a", "b"] }
// jsf génère { "a": "..." } → invalide ("b" requis mais absent)

Analyse comparative des approches

Les trois générateurs reflètent deux philosophies distinctes :

• Approche optimiste pure (json-schema-faker, json-everything) - génération rapide mais invalidité résiduelle sur les combinaisons de contraintes complexes (not, oneOf, allOf croisés). La correction par validateur externe améliore le taux de validité mais ne résout pas les cas structurellement incompatibles.
• Approche template (json-data-generator) - fidélité supérieure sur les schémas simples, mais couverture incomplète du standard et absence de support pour les mots-clés combinatoires.

La rétro-ingénierie révèle que les erreurs de json-schema-faker se concentrent sur les schémas issus de Kubernetes (domaine le plus contraint) : les définitions CRD Kubernetes exploitent massivement oneOf et not, deux des cas de défaillance identifiés.