Поблочное тестирование [закрытое] Поколение XML

Во-первых, как в значительной степени все говорят, проверьте XML, если существует схема, определенная для него. (Если нет, определите тот.)

, Но можно создать тесты, которые намного более детализированы, чем это путем выполнения запросов XPath против документа, например:

string xml="Your xml string here" ;
XmlDocument doc = new XmlDocument();
doc.LoadXml(xml);
path = "/doc/element1[@id='key1']/element2[. = 'value2']";
Assert.IsTrue(doc.SelectSingleNode(path) != null);

Это позволяет Вам протестировать не только, действителен ли Ваш документ семантически, но и заполняет ли метод, производящий его, его со значениями, которые Вы ожидаете.

почему бы не предполагать, что некоторый коммерческий xml синтаксический анализатор корректен и проверяет Ваш код XML против него? что-то как.

Assert.IsTrue(myDoc.Xml.ParseOK)

кроме этого и если бы Вы хотите быть полными, я сказал бы, что необходимо было бы создать синтаксический анализатор сами и проверить каждое правило, которого требует спецификация XML.

Другая причина использовать Схему для проверки против состоит в том, что, в то время как узлы XML явно заказаны, атрибуты XML не.

Так Ваше сравнение строк:

Assert.AreEqual(myDoc.OuterXML(),"big string of XML")

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

Проверьте против XML-схемы или DTD, также ключ от английского замка, что узлы имеют значения, которые Вы ожидаете.

Если у Вас есть стандартный формат, который Вы ожидаете, что вывод будет, почему бы не создаст XML-схему или DTD и проверит против этого. Это не будет зависеть от данных, быть гибким - также. Также определение, как XML может быть сформирован, может быть полезным при разработке Вас система.

Проверьте его против использования схемы XSD класс XmlSchema. Его найденный в соответствии с System.XML я думаю. Другая опция состояла бы в том, чтобы записать класс сериализации (XMLSerializer) для десериализации XML в объект. Усиление будет то, что это неявно проверит Вашу структуру, и после этого к значениям можно легко получить доступ для тестирования использования полученного объекта.

XMLUnit может помочь Вам.

Другая возможность могла бы состоять в том, чтобы использовать XmlReader и проверить на ошибочное количество> 0. Что-то вроде этого:

    void CheckXml()
    {
        string _xmlFile = "this.xml";
        string _xsdFile = "schema.xsd"; 
        StringCollection _xmlErrors = new StringCollection();

        XmlReader reader = null;
        XmlReaderSettings settings = new XmlReaderSettings();
        settings.ValidationEventHandler += new ValidationEventHandler(this.ValidationEventHandler);
        settings.ValidationType = ValidationType.Schema;
        settings.IgnoreComments = chkIgnoreComments.Checked;
        settings.IgnoreProcessingInstructions = chkIgnoreProcessingInstructions.Checked;
        settings.IgnoreWhitespace = chkIgnoreWhiteSpace.Checked;
        settings.Schemas.Add(null, XmlReader.Create(_xsdFile));
        reader = XmlReader.Create(_xmlFile, settings);
        while (reader.Read())
        {
        }
        reader.Close();
        Assert.AreEqual(_xmlErrors.Count,0);
    }    

    void ValidationEventHandler(object sender, ValidationEventArgs args)
    {
        _xmlErrors.Add("<" + args.Severity + "> " + args.Message);
    }

Убедитесь, что результирующий документ правильно сформирован Убедиться, что результирующий документ действителен Убедиться в правильности результирующего документа.

Предположительно, вы создаете XML-документ из полезных данных, поэтому вы захотите убедиться, что у вас есть правильный охват входных данных для ваших тестов. Наиболее распространенными проблемами, которые я вижу, являются

• Неправильно приведенные элементы
• Неправильно приведенные атрибуты
• Неправильно приведенные имена элементов
• Неправильно приведенные имена атрибутов

Поэтому, если вы еще не сделали этого, вам нужно просмотреть спецификацию XML, чтобы узнать, что разрешено в каждом месте.

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

Для более крупных автоматизированных тестов, когда вы хотите проверить весь документ, то, что я нашел эффективным, это иметь Ожидаемые результаты, которые также являются документом, и проходить по нему узел за узлом, используя выражения XPath для поиска соответствующего узла в реальном документе, а затем применяя правильное сравнение данных, закодированных в этих двух узлах.

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

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