Doit-on tester un schéma XML?

Question

Je suis dans les toutes premières étapes de l'écriture de schéma XML pour l'application d'entreprise de mon travail. Le XML à valider représente une application - similaire à Winforms - formulaires, grilles, menus etc mais sans mise en page. Le but principal du XSD n'est pas tant de valider le XML que d'ajouter une reconnaissance de conception au fichier XML, de sorte que l'on obtiendrait IntelliSense pour les éléments et les attributs disponibles. Lorsque j'écris le schéma, je me suis retrouvé à faire des éléments de TDD et à valider un document par rapport au schéma, en changeant les éléments/attributs dans le document ou dans le schéma pour que la validation échoue. schéma correctement. Ceci m'amène à la question de savoir si je devrais ou non tester le schéma par unité, juste pour lancer quelques permutations du XML et m'assurer qu'il se comporte comme il le devrait.

Cela aurait certainement du sens pour moi car mon XSD-fu est abyssal et je veux être encore plus sûr que le XSD, qui est en fait une spécification en soi, est correct.

Answer 1

En général, je trouve qu'il est très difficile de tester les schémas XSD:

• Pour XSD souvent la modélisation de votre domaine est la clé, souvent je n'ai pas eu des problèmes avec le XSD se construit mais j'analysé le domaine faux.
• Le modèle généré n'est pas basé sur le XSD lui-même, mais également sur la configuration de liaison (par exemple JAXB pour Java). Donc, à la fin, vous testez trop.
• Ces tests dépendant de beaucoup de choses ont tendance à se casser souvent, surtout lorsque vous refactorisez le XSD.

En fin de compte pour améliorer la qualité de XSD je préfère:

• ont des critiques au début de XSD (par des collègues ou QA). Le fait que les gens les regardent (à la fois les instances XSD et XML) a permis de découvrir des failles qui n'auraient jamais été découvertes par des tests automatisés.
• Effectuez des tests d'intégration sur les instances XML générées. Ces tests d'intégration peuvent être automatisés.

Answer 2

Si vous n'êtes pas bon avec XSD, alors je vous recommande de construire le XSD en utilisant TDD. C'est-à-dire, créer un test unitaire défaillant, impliquant la validation de certains XML que vous voulez faire travailler, et un XSD qui ne permettra pas de le valider. Ensuite, mettez à jour le XSD pour permettre à ce XML de valider. Ensuite, refactoriser le test et le XSD, en répétant les tests.

Answer 3

Je suppose qu'il n'y a aucune raison de ne pas tester un schéma XML. S'il s'agit de code (ce qui est le cas), alors TDD favorisera le test.

L'autre question sera comment s'y prendre? Une approche simple consiste à créer deux groupes de fichiers xml, l'un contenant tous les fichiers qui ne sont pas valides selon votre conception et l'autre contenant des fichiers valides. Ensuite, il suffit d'analyser chaque groupe avec votre analyseur XML et d'affirmer les résultats.

Mais le véritable défi réside dans la création des exemples de fichiers XML. Surtout si vous faites évoluer votre design simultanément.