¿Debo probar el esquema XML de la unidad?

Question

Estoy en las primeras etapas de escribir el esquema XML para la aplicación empresarial de mi trabajo. El XML que debe validarse representa una aplicación, similar a Winforms, formularios, cuadrículas, menús, etc., pero sin diseño.

El objetivo principal del XSD no es tanto validar el XML como agregar la capacidad de descubrimiento en tiempo de diseño al archivo XML, de modo que uno obtenga IntelliSense para los elementos y atributos disponibles.

Como estoy escribiendo el esquema me he encontrado haciendo elementos de TDD y validando un documento contra el esquema, cambiando los elementos/atributos en el documento o en el esquema para hacer que la validación no se asegure de estar escribiendo el esquema correctamente

Esto me lleva a la pregunta de si debo o no probar el esquema por unidades, solo para arrojar algunas permutaciones del XML y asegurarme de que se comporta como debe.

Definitivamente tendría sentido para mí, ya que mi XSD-fu es abismal y quiero estar aún más seguro de que el XSD, que en efecto ES una especificación en sí mismo, es correcto.

Answer 1

Generalmente me resulta muy difícil probar esquemas XSD:

• Para XSD menudo el modelado de su dominio es la clave, a menudo no tenía problemas con el XSD construye a sí misma, pero he analizado el dominio incorrecto.
• El modelo generado no se basa en el XSD en sí mismo, sino también en la configuración de enlace (por ejemplo, JAXB para Java). Entonces al final estás probando demasiado.
• Tales pruebas, dependiendo de muchas cosas, tienden a romperse con frecuencia, especialmente cuando se refactoriza el XSD.

Al final para mejorar la calidad XSD prefiero:

• Tener las primeras críticas de XSD (por colegas o QA). Al ver personas reales (tanto instancias XSD como XML) descubrieron fallas que las pruebas automatizadas nunca habrían descubierto.
• Hacer pruebas de integración en las instancias XML generadas. Estas pruebas de integración pueden ser automatizadas.

Answer 2

Si no eres bueno con XSD, entonces te recomiendo que construyas el XSD usando TDD. Es decir, crea una prueba unitaria fallida, que implica la validación de algún XML que quieras que funcione, y un XSD que no le permitirá validar. Luego, actualice el XSD para permitir que XML valide. Luego, refactorice la prueba y el XSD, repitiendo las pruebas.

Answer 3

Supongo que no hay ninguna razón para no probar XML Schema. Si es un código (que es), entonces TDD favorecerá la prueba.

La otra pregunta será cómo hacerlo? Un enfoque simple será crear dos grupos de archivos xml de muestra, uno que contenga todos los archivos que no son válidos de acuerdo con su diseño y el otro que contenga archivos que sean válidos. Luego simplemente analiza cada grupo con tu analizador xml y afirma los resultados.

Pero el desafío real residirá en crear los archivos xml de muestra. Especialmente si también está evolucionando su diseño simultáneamente.