Регрессионное тестирование на эквивалентность схемы (xsd) - PullRequest
1 голос
/ 17 декабря 2009

Я думаю о переписывании схемы с множеством автономных сложных типов, в которую сложные типы более разумно расширяют другие базовые типы. Обоснование этого является частично концептуальным - поскольку большинство этих типов являются конкретными экземплярами объекта домена с определенной иерархической структурой - и частично практичным, потому что мы используем сгенерированные JAXB классы для обработки логики чтения XML, и невозможно писать методы для общей функциональности без отражения или большого количества instanceof и приведения. BLEH.

Итак, мой основной вопрос: знает ли кто-нибудь о хорошем способе проверки двух схем XSD на функциональную эквивалентность? Если я правильно выполню рефакторинг этой схемы, набор документов, которые будут считаться действительными, должен быть одинаковым для двух схем, несмотря на тот факт, что сами файлы будут сильно отличаться. Это похоже на то, с чем может помочь среда тестирования; Я знаю, что есть инструменты, которые будут предлагать входные данные для тестов JUnit, и мне было интересно, могут ли быть какие-либо инструменты для генерации XML-документов пограничного случая для проверки на соответствие старой и новой схемам?

И в качестве отступления - если это ужасная идея (или если есть лучшие альтернативы), тогда остановите меня сейчас. : -)

Спасибо за внимание.

Ответы [ 2 ]

2 голосов
/ 18 декабря 2009

общего ответа на эту проблему нет, так как вопрос о том, эквивалентны ли две контекстно-свободные грамматики, неразрешим. См. эту страницу википедии .

Была проделана некоторая теоретическая работа по этому вопросу, но нет ни одного инструмента, упакованного с полки, чтобы сделать это для вас.

Вы можете решить эту проблему, если сделаете определенные предположения о том, как разрабатывать свою схему (запрет анонимных типов, соглашения об именах и т. Д.). Затем вы можете использовать библиотеку типа eclipse XSD (которая отлично работает вне eclipse в автономном приложении) для выполнения сравнения.

Наконец, вот ссылка на исследовательскую работу , в которой более подробно обсуждается проблема.

2 голосов
/ 17 декабря 2009

После некоторого расследования я наткнулся на Liquid XML Sample Generator , который звучит именно так, как я бы искал (хотя я не уверен, вполне насколько хорошо это было бы для тестирования крайних случаев).

Я также наткнулся на SUT: модульный тест схемы XML , который больше не нуждается в активном ведении или хорошо документирован, но использует более программный подход к определению того, какие документы XML должны быть действительными или недействительными для данной схемы, и тестирование этого. К сожалению, контрольные примеры, по-видимому, интерпретируются линейно, а не переставляют возможности для каждого отдельного узла, как это сделал бы приведенный выше генератор примеров XML. Следовательно, в то время как было бы возможно обеспечить лучшее освещение, вероятно, было бы много работы для этого.

Так что, по крайней мере, у меня есть то, что кажется работоспособным запасным вариантом - создание пакета документов из старой схемы, а затем проверка их по новой схеме и наоборот. Это не является окончательным (ну, в любом случае, юнит-тесты никогда не бывают), но выполнение нескольких сотен или тысяч тестов в каждом направлении должно дать довольно хорошую уверенность в том, что схемы эквивалентны.

Я был бы очень рад представить элегантное решение для тестирования, но после часа поиска в Google я не оставляю особой надежды, что что-то в этом роде существует.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...