Должен я XML-схема модульного теста?
Я нахожусь на очень ранних стадиях записи XML-схемы для корпоративного приложения моей работы. XML, который будет проверен, представляет приложение - подобный Winforms - формы, сетки, меню и т.д., но без расположения.
Главная цель XSD не так, чтобы проверить XML, но добавить время проектирования discoverability к XML-файлу, так, чтобы можно было бы получить IntelliSense для доступных элементов и атрибутов.
Поскольку я описываю схему, я делал элементы TDD и проверить документ против схемы, изменяясь или элементы/атрибуты в документе или в схеме, чтобы заставить проверке не удаться удостовериться, что я пишу схему правильно.
Это приносит мне к вопросу того, должен ли я быть поблочным тестированием схема, только чтобы бросить несколько перестановок XML в нем и удостовериться, что он ведет себя, как он, как предполагается.
Это, конечно, имело бы смысл мне, поскольку мой XSD-fu плачевен, и я хочу быть еще более уверенным XSD, который в действительности ЯВЛЯЕТСЯ спецификацией отдельно, корректно.
3 ответа
Как правило, мне очень трудно проверить XSD Schemas:
- для XSD часто моделирования вашего Домен - это ключ, часто у меня не было проблем с самих задач XSD, но я проанализировал домен не так.
- Сгенерированная модель не основана на сам XSD, но и на конфигурации связывания (например, jaxb для Java). Итак, в конце концов вы слишком много тестируете.
- Такие тесты в зависимости от множества вещей, как правило, часто ломаются, особенно когда вы рекакторуете XSD.
В конце концов, чтобы улучшить качество XSD, которое я предпочитаю:
- имеют ранние обзоры XSDS (по коллегам или Qa). Наличие реальных людей смотрит на них (как XSD, так и XML-экземпляры), обнаруженные недостатки, которые никогда не были обнаружены автоматическими тестированием.
- Сделайте тестирование интеграции на сгенерированных экземплярах XML. Эти тесты интеграции могут быть автоматизированы.
Если вы плохо работаете с XSD, то я рекомендую построить XSD с помощью TDD. То есть, создайте неудачный юнит-тест, включающий в себя проверку некоторого XML, который должен работать, и XSD, который не позволит проверить его. Затем обновите XSD, чтобы она разрешила этот XML. Затем рефакторизуйте тест и XSD, повторяя тесты.
Я думаю, нет никаких причин, чтобы не установить тестирование XML-схемы. Если это код (который оно есть), то TDD будет способствовать его тестированию.
Другой вопрос будет как это пойти? Простой подход будет создавать две группы файлов образца XML, которые содержат все файлы, которые недействительны в соответствии с вашим дизайном, а другие, содержащие файлы, которые действительны. Затем просто разбирайте каждую группу с помощью своего анализатора XML и утвердите результаты.
Но фактическая задача будет заключаться в создании образца файлов XML. Особенно, если вы также развиваете свой дизайн одновременно.