davidehringer / xml-matchers Goto Github PK

I need an XpathReturnType for xpath expressions that match a node list:

public static XpathReturnType<NodeList> returningAnXmlNodeList() {
      return new XpathReturnType<NodeList>() {
              @Override
              QName evaluationMode() {
                      return XPathConstants.NODESET;
              }};
   }

The attached maven project proofs (JUnit test included) that prefixes and sort 
orders are checked too restrictive. AFAIK, according to the XML specifications 
it plays no role whether prefixes are used or not, or what name these have, as 
long as they refer to the same namespace URL.

Out of this assumption result the bugs I found:

(1) Test fails because expected was "D:" but actual was "d:".
(2) Test fails because expected was "D:" but actual was "P:".
(3) Test fails because expected was "D:" but actual was default namespace.

Another bug I found is that AFAIK the order of XML elements plays no role 
unless a specific order is specified explicitly using a schema:

(4) Test fails due to different order of elements, but no schema is provided to 
enforce this.

Looks like XPath 2.0 is not supported:

assertThat(
  XmlConverters.the(xml),
  org.xmlmatchers.XmlMatchers.hasXPath("//a[ends-with(@id, '-test')]")
);

Leads to:

java.lang.IllegalArgumentException: Invalid XPath : //a[ends-with(@id, '-test')]
    at org.xmlmatchers.xpath.HasXPath.<init>(HasXPath.java:81)
    at org.xmlmatchers.xpath.HasXPath.<init>(HasXPath.java:63)
    at org.xmlmatchers.xpath.HasXPath.<init>(HasXPath.java:58)
    at org.xmlmatchers.xpath.HasXPath.hasXPath(HasXPath.java:146)
    at org.xmlmatchers.XmlMatchers.hasXPath(XmlMatchers.java:27)
        .........

The function `returningAnXmlNode` has the signature:

    public static XpathReturnType<String> returningAnXmlNode()

This seems odd, given that it matches against a `Source` object. Somehow, JDK 7 
manages to compile it regardless, but it still seems incorrect.

IntelliJ IDEA flags it as an error and refuses to build it. This is not a 
massive concern, as it can still be built through the command line (though it 
is quite annoying).

I might be missing something, but if not, could we update the signature (and 
implementation) to return an XpathReturnType<Source>?

Thanks for an excellent library.

— Samir.

The following test example show how you can't do what you might think you want 
to do.

    @Test
    @Ignore("Using a Source breaks this use case")
    public void theResultOfTheXpathCanMatchedUsingEquivalentToWhenTheResultIsAnXmlFragment() {
//      assertThat(
//              xml,
//              hasXPath("/mountains/mountain[@id='a']/name",
//                      returningAnXmlNode(),
//                      equivalentTo("<name>Everest</name>")));
    }

    @Test
    @Ignore("Using a Source breaks this use case")
    public void matchingNodesCanBeTestedForEquivalence() {
//      assertThat(
//              xml,
//              hasXPath(
//                      "/mountains/mountain[@id='a']/name",
//                      returningAnXmlNode(),
//                      equivalentTo("<name><!-- some comment -->Everest</name>")));
    }

I'd like to be able to get at the underlying exception, rather than just know 
*whether* the XML was invalid. 

This leads to hard to debug assertion failures. Maybe this method could be 
improved:

public static Source the(Node node) {
 return new DOMSource(node);
}

Possibly it could be implemented as

public static Source the(Node node) {
 return new DOMSource(node){
            @Override
            public String toString()
            {
               return node.toString();
            }};
}

Keeping up with Hamcrest updates.

org.xmlmatchers.xpath.XpathReturnType.evaluationMode() is marked as package 
visibility. 

public abstract class XpathReturnType<T> {
    abstract QName evaluationMode();
}

If it were "protected" visibility new XpathReturnTypes could be added:

public abstract class XpathReturnType<T> {
    protected abstract QName evaluationMode();
}

The problem arises when I create a test that reads XML from a string, does some 
processing and then uses XmlMatchers to validate the resulting XML.

It works fine when running in an UTF-8 environment, but on my ISO-8859-1 build 
server the test fails with: MalformedByteSequenceException: Invalid byte 1 of 
1-byte UTF-8 sequence. Coming from within the StringSource constructor.

When creating the ByteArrayInputStream for the DocumentBuilder, you currently 
call String.getBytes(). I would like to see an alternative constructor that 
allows passing a Charset so we can call String.getBytes(Charset) instead. 

This way we got full control over the encoding used.