Robot Framework test library for verifying and modifying XML documents.

As the name implies, XML is a test library for verifying contents of XML files. In practice it is a pretty thin wrapper on top of Python's ElementTree XML API.

The library has the following main usages:

Table of contents

Parsing XML

XML can be parsed into an element structure using Parse XML keyword. The XML to be parsed can be specified using a path to an XML file or as a string or bytes that contain XML directly. The keyword returns the root element of the structure, which then contains other elements as its children and their children. Possible comments and processing instructions in the source XML are removed.

XML is not validated during parsing even if has a schema defined. How possible doctype elements are handled otherwise depends on the used XML module and on the platform. The standard ElementTree strips doctypes altogether but when using lxml they are preserved when XML is saved.

The element structure returned by Parse XML, as well as elements returned by keywords such as Get Element, can be used as the source argument with other keywords. In addition to an already parsed XML structure, other keywords also accept paths to XML files and strings containing XML similarly as Parse XML. Notice that keywords that modify XML do not write those changes back to disk even if the source would be given as a path to a file. Changes must always saved explicitly using Save XML keyword.

When the source is given as a path to a file, the forward slash character (/) can be used as the path separator regardless the operating system. On Windows also the backslash works, but it the test data it needs to be escaped by doubling it (\\). Using the built-in variable ${/} naturally works too.

Note: Support for XML as bytes is new in Robot Framework 3.2.

Using lxml

By default this library uses Python's standard ElementTree module for parsing XML, but it can be configured to use lxml module instead when importing the library. The resulting element structure has same API regardless which module is used for parsing.

The main benefits of using lxml is that it supports richer xpath syntax than the standard ElementTree and enables using Evaluate Xpath keyword. It also preserves the doctype and possible namespace prefixes saving XML.


The following simple example demonstrates parsing XML and verifying its contents both using keywords in this library and in BuiltIn and Collections libraries. How to use xpath expressions to find elements and what attributes the returned elements contain are discussed, with more examples, in Finding elements with xpath and Element attributes sections.

In this example, as well as in many other examples in this documentation, ${XML} refers to the following example XML document. In practice ${XML} could either be a path to an XML file or it could contain the XML itself.

  <first id="1">text</first>
  <second id="2">
    <child>more text</child>
    <second id="child"/>
      Text with <b>bold</b> and <i>italics</i>.
${root} = Parse XML ${XML}
Should Be Equal ${root.tag} example
${first} = Get Element ${root} first
Should Be Equal ${first.text} text
Dictionary Should Contain Key ${first.attrib} id
Element Text Should Be ${first} text
Element Attribute Should Be ${first} id 1
Element Attribute Should Be ${root} id 1 xpath=first
Element Attribute Should Be ${XML} id 1 xpath=first

Notice that in the example three last lines are equivalent. Which one to use in practice depends on which other elements you need to get or verify. If you only need to do one verification, using the last line alone would suffice. If more verifications are needed, parsing the XML with Parse XML only once would be more efficient.

Finding elements with xpath

ElementTree, and thus also this library, supports finding elements using xpath expressions. ElementTree does not, however, support the full xpath standard. The supported xpath syntax is explained below and ElementTree documentation provides more details. In the examples ${XML} refers to the same XML structure as in the earlier example.

If lxml support is enabled when importing the library, the whole xpath 1.0 standard is supported. That includes everything listed below but also lot of other useful constructs.

Tag names

When just a single tag name is used, xpath matches all direct child elements that have that tag name.

${elem} = Get Element ${XML} third
Should Be Equal ${elem.tag} third
@{children} = Get Elements ${elem} child
Length Should Be ${children} 2


Paths are created by combining tag names with a forward slash (/). For example, parent/child matches all child elements under parent element. Notice that if there are multiple parent elements that all have child elements, parent/child xpath will match all these child elements.

${elem} = Get Element ${XML} second/child
Should Be Equal ${elem.tag} child
${elem} = Get Element ${XML} third/child/grandchild
Should Be Equal ${elem.tag} grandchild


An asterisk (*) can be used in paths instead of a tag name to denote any element.

@{children} = Get Elements ${XML} */child
Length Should Be ${children} 3

Current element

The current element is denoted with a dot (.). Normally the current element is implicit and does not need to be included in the xpath.

Parent element

The parent element of another element is denoted with two dots (..). Notice that it is not possible to refer to the parent of the current element.

${elem} = Get Element ${XML} */second/..
Should Be Equal ${elem.tag} third

Two forward slashes (//) mean that all sub elements, not only the direct children, are searched. If the search is started from the current element, an explicit dot is required.

@{elements} = Get Elements ${XML} .//second
Length Should Be ${elements} 2
${b} = Get Element ${XML} html//b
Should Be Equal ${b.text} bold


Predicates allow selecting elements using also other criteria than tag names, for example, attributes or position. They are specified after the normal tag name or path using syntax path[predicate]. The path can have wildcards and other special syntax explained earlier. What predicates the standard ElementTree supports is explained in the table below.

Predicate Matches Example
@attrib Elements with attribute attrib. second[@id]
@attrib="value" Elements with attribute attrib having value value. *[@id="2"]
position Elements at the specified position. Position can be an integer (starting from 1), expression last(), or relative expression like last() - 1. third/child[1]
tag Elements with a child element named tag. third/child[grandchild]

Predicates can also be stacked like path[predicate1][predicate2]. A limitation is that possible position predicate must always be first.

Element attributes

All keywords returning elements, such as Parse XML, and Get Element, return ElementTree's Element objects. These elements can be used as inputs for other keywords, but they also contain several useful attributes that can be accessed directly using the extended variable syntax.

The attributes that are both useful and convenient to use in the test data are explained below. Also other attributes, including methods, can be accessed, but that is typically better to do in custom libraries than directly in the test data.

The examples use the same ${XML} structure as the earlier examples.


The tag of the element.

${root} = Parse XML ${XML}
Should Be Equal ${root.tag} example


The text that the element contains or Python None if the element has no text. Notice that the text does not contain texts of possible child elements nor text after or between children. Notice also that in XML whitespace is significant, so the text contains also possible indentation and newlines. To get also text of the possible children, optionally whitespace normalized, use Get Element Text keyword.

${1st} = Get Element ${XML} first
Should Be Equal ${1st.text} text
${2nd} = Get Element ${XML} second/child
Should Be Equal ${2nd.text} ${NONE}
${p} = Get Element ${XML} html/p
Should Be Equal ${p.text} \n${SPACE*6}Text with${SPACE}


The text after the element before the next opening or closing tag. Python None if the element has no tail. Similarly as with text, also tail contains possible indentation and newlines.

${b} = Get Element ${XML} html/p/b
Should Be Equal ${b.tail} ${SPACE}and${SPACE}


A Python dictionary containing attributes of the element.

${2nd} = Get Element ${XML} second
Should Be Equal ${2nd.attrib['id']} 2
${3rd} = Get Element ${XML} third
Should Be Empty ${3rd.attrib}

Handling XML namespaces

ElementTree and lxml handle possible namespaces in XML documents by adding the namespace URI to tag names in so called Clark Notation. That is inconvenient especially with xpaths, and by default this library strips those namespaces away and moves them to xmlns attribute instead. That can be avoided by passing keep_clark_notation argument to Parse XML keyword. Alternatively Parse XML supports stripping namespace information altogether by using strip_namespaces argument. The pros and cons of different approaches are discussed in more detail below.

How ElementTree handles namespaces

If an XML document has namespaces, ElementTree adds namespace information to tag names in Clark Notation (e.g. {http://ns.uri}tag) and removes original xmlns attributes. This is done both with default namespaces and with namespaces with a prefix. How it works in practice is illustrated by the following example, where ${NS} variable contains this XML document:

<xsl:stylesheet xmlns:xsl=""
  <xsl:template match="/">
${root} = Parse XML ${NS} keep_clark_notation=yes
Should Be Equal ${root.tag} {}stylesheet
Element Should Exist ${root} {}template/{}html
Should Be Empty ${root.attrib}

As you can see, including the namespace URI in tag names makes xpaths really long and complex.

If you save the XML, ElementTree moves namespace information back to xmlns attributes. Unfortunately it does not restore the original prefixes:

<ns0:stylesheet xmlns:ns0="">
  <ns0:template match="/">
    <ns1:html xmlns:ns1=""></ns1:html>

The resulting output is semantically same as the original, but mangling prefixes like this may still not be desirable. Notice also that the actual output depends slightly on ElementTree version.

Default namespace handling

Because the way ElementTree handles namespaces makes xpaths so complicated, this library, by default, strips namespaces from tag names and moves that information back to xmlns attributes. How this works in practice is shown by the example below, where ${NS} variable contains the same XML document as in the previous example.

${root} = Parse XML ${NS}
Should Be Equal ${root.tag} stylesheet
Element Should Exist ${root} template/html
Element Attribute Should Be ${root} xmlns
Element Attribute Should Be ${root} xmlns xpath=template/html

Now that tags do not contain namespace information, xpaths are simple again.

A minor limitation of this approach is that namespace prefixes are lost. As a result the saved output is not exactly same as the original one in this case either:

<stylesheet xmlns="">
  <template match="/">
    <html xmlns=""></html>

Also this output is semantically same as the original. If the original XML had only default namespaces, the output would also look identical.

Namespaces when using lxml

This library handles namespaces same way both when using lxml and when not using it. There are, however, differences how lxml internally handles namespaces compared to the standard ElementTree. The main difference is that lxml stores information about namespace prefixes and they are thus preserved if XML is saved. Another visible difference is that lxml includes namespace information in child elements got with Get Element if the parent element has namespaces.

Stripping namespaces altogether

Because namespaces often add unnecessary complexity, Parse XML supports stripping them altogether by using strip_namespaces=True. When this option is enabled, namespaces are not shown anywhere nor are they included if XML is saved.

Attribute namespaces

Attributes in XML documents are, by default, in the same namespaces as the element they belong to. It is possible to use different namespaces by using prefixes, but this is pretty rare.

If an attribute has a namespace prefix, ElementTree will replace it with Clark Notation the same way it handles elements. Because stripping namespaces from attributes could cause attribute conflicts, this library does not handle attribute namespaces at all. Thus the following example works the same way regardless how namespaces are handled.

${root} = Parse XML <root id="1" ns:id="2" xmlns:ns="http://my.ns"/>
Element Attribute Should Be ${root} id 1
Element Attribute Should Be ${root} {http://my.ns}id 2

Boolean arguments

Some keywords accept arguments that are handled as Boolean values true or false. If such an argument is given as a string, it is considered false if it is an empty string or equal to FALSE, NONE, NO, OFF or 0, case-insensitively. Other strings are considered true regardless their value, and other argument types are tested using the same rules as in Python.

True examples:

Parse XML ${XML} keep_clark_notation=True # Strings are generally true.
Parse XML ${XML} keep_clark_notation=yes # Same as the above.
Parse XML ${XML} keep_clark_notation=${TRUE} # Python True is true.
Parse XML ${XML} keep_clark_notation=${42} # Numbers other than 0 are true.

False examples:

Parse XML ${XML} keep_clark_notation=False # String false is false.
Parse XML ${XML} keep_clark_notation=no # Also string no is false.
Parse XML ${XML} keep_clark_notation=${EMPTY} # Empty string is false.
Parse XML ${XML} keep_clark_notation=${FALSE} # Python False is false.

Considering string NONE false is new in Robot Framework 3.0.3 and considering also OFF and 0 false is new in Robot Framework 3.1.

Pattern matching

Some keywords, for example Elements Should Match, support so called glob patterns where:

* matches any string, even an empty string
? matches any single character
[chars] matches one character in the bracket
[!chars] matches one character not in the bracket
[a-z] matches one character from the range in the bracket
[!a-z] matches one character not from the range in the bracket

Unlike with glob patterns normally, path separator characters / and \ and the newline character \n are matches by the above wildcards.

Support for brackets like [abc] and [!a-z] is new in Robot Framework 3.1