xmlunit-general — Everything XMLUnit ;0)

Re: [Xmlunit-general] ComparisonControllers.StopWhenSimilar

[Harald B. <bra...@gm...>]

Hi,

I would like to make the CompareMatcher extendable.
This means that the constructor and two methods must be protected instead private.
I created an Example usage in the UnitTest:
https://github.com/brabenetz/xmlunit/commit/8479be3c9192bac073460002f55a6f5c1238c46b#diff-be4be35ef4f91a64f60bae29d9c22e8fR343

This example is basically what I do with the Matcher on my current Project: I write the test-Input into the FileSystem, where I can manual review it.
And when the changes are OK I can simply overwrite my control-File with the written Test-File.

Alternative (CompareMatcher not extendable because of private constructor) I could write a custom "assertThat()" method in my current project which would do the same thing.
At least for my current project it is cleaner to extends the Matcher: In all my Tests I only need the extended Matcher instead of the compination of the CompareMatcher AND a custom "assertThat" method.

On the other hand it is more difficult to maintain a Class which can be extended.

Please let me know what you think.

with friendly regards,
Harald

Re: [Xmlunit-general] ComparisonControllers.StopWhenSimilar

[Stefan B. <bo...@ap...>]

On 2015-02-15, Harald Brabenetz wrote:

> I improved the JaxbBuilder and implemented JaxbBuilder.useObjectFactory().
> https://github.com/brabenetz/xmlunit/commit/1aaabfc5b880b0dc81c7b896f545b5130fa0d603
> I will prepare a pull request for it.

OK.  This reminds me I wanted to look into supporting
XML-deserialization for .NET as well.

> I also tested the current XmlUnit 2.x implementation on my current Project.
> Everything woks fine.

Great, thanks.

> But one Question:
> Why is the return type of "Comparison.getControlDetails().getTarget()" an Object?
> Is there any case where the return Object is not a org.w3c.dom.Node?

This is likely part of the somewhat ambiguos API in the diff package.
Parts of it try to abstract from DOM, other parts are tied to it.  If we
agreed to embrace DOM as part of XMLUnit's diff API, then we may as well
switch to Node here.

Stefan

Re: [Xmlunit-general] ComparisonControllers.StopWhenSimilar

[Harald B. <bra...@gm...>]

I improved the JaxbBuilder and implemented JaxbBuilder.useObjectFactory().
https://github.com/brabenetz/xmlunit/commit/1aaabfc5b880b0dc81c7b896f545b5130fa0d603
I will prepare a pull request for it.

I also tested the current XmlUnit 2.x implementation on my current Project.
Everything woks fine.
But one Question:
Why is the return type of "Comparison.getControlDetails().getTarget()" an Object?
Is there any case where the return Object is not a org.w3c.dom.Node?

I think I can use the changes for a migration documentation (see Attachment).

with friendly regards,
Harald

Re: [Xmlunit-general] Advanced ElementSelectors

[Stefan B. <bo...@ap...>]

On 2015-02-10, Stefan Bodewig wrote:

> one could use something like

>     byXPath(".//a", byNameAndText)

> ...  The corresponding selector
> would run the Nodes returned by evaluating the XPath through a
> comparison process and match the elements if all nodes returned could be
> matched.

I've committed a first version of this.  It works but likely isn't
performing too well because of repeated XPath evaluations inside the
same context - some memoization could help if the number of elements to
compare is big.

> But I'm not sure this really is easy enough to understand and I'm afraid
> it would become repetitive.  So a better idea is more than welcome.

This still holds true :-)

Stefan

Re: [Xmlunit-general] Adding toString() for Comparison

[Stefan B. <bo...@ap...>]

Hi Will

On 2015-02-11, Will Herrmann wrote:

> Stefan had suggested delegating the creation of the toString() to
> ComparisonFormatter and it looks like DefaultComparisonFormatter would
> do the trick and be pretty simple to implement. Would this be an
> acceptable solution?

Yes, it would.  Maybe do something similar to Diff with a toString
overload that accepts a ComparisonFormatter.  It would probably be a
good idea to take care of the Difference class at the same time.

Cheers

        Stefan

[Xmlunit-general] Adding toString() for Comparison

[Will H. <wjh...@gm...>]

Hello Everyone,

I've been in contact with Stefan Bodewig about an issue I encountered with XMLUnit 2.0 and I'd like to help out to fix it!

The main GitHub page provides an example of how to test a comparison, which includes the following code:

Assert.fail("found a difference: " + comparison);

The trouble with this is that the Comparison class does not have a toString() message, thus the assertion failure just shows the Comparison's memory location and is useless to someone reading the error log. I'd like to rectify that by adding a proper toString() method.

Stefan had suggested delegating the creation of the toString() to ComparisonFormatter and it looks like DefaultComparisonFormatter would do the trick and be pretty simple to implement. Would this be an acceptable solution?

Thanks in Advance,
-Will Herrmann

Re: [Xmlunit-general] Cleaned Up DifferenceEngine

[Stefan B. <bo...@ap...>]

On 2015-02-04, Stefan Bodewig wrote:

> when I added ComparisonController I used Map.Entry as a quick hack, this
> has now been cleaned up a little in a branch named
> diff-engine-alternative (both in xmlunit and xmlunit.net).  I'd
> appreciate a quick review of the changes.

merged by now.

Stefan

[Xmlunit-general] Advanced ElementSelectors

[Stefan B. <bo...@ap...>]

Hi all

the concept of ElementQualifier in XMLUnit 1.x and its cousin
ElementSelector in 2.x seems to be difficult.  Almost all questions I've
answered in the past years and many of the issues I closed have been
related to not understanding the concept or chosing the wrong
ElementQualifier - usually RecursiveElementNameAndTextQualifier.

We need to explain it better, which is part of what we need to do in the
new user guide, but we also need to make it easier to customize the
selection process.

I've started to implement "combinators" for ElementSelectors based on
ideas Bastain Blankenburg expressed as feature requests about - what? -
five years ago.  So you can now do something like

import static org.xmlunit.diff.ElementSelectors.*;

ElementSelector es = or(selectorForElementNamed("foo", byNameAndText),
                        selectorForElementNamed("bar", byNameAndAttributes("id")),
                        byName);

in order to pick foos based on their nested text, bars based on an
attribute and solely rely on the name by default.  This is a big step
forward and I can also see some nice builder syntax forming

ElementSelector es = Builder
    .whenElementIsNamed("foo").thenUse(byNameAndText)
    .whenElementIsNamed("bar").thenUse(byNameAndAttributes("id"))
    .otherwise(byName)
    .build();

To get rid of RecursiveElementNameAndTextQualifier this is not enough,
back then Bastian suggested a child element qualifier, which would be a
combinator that picked a child node and applied a different selector.
This falls short for recursion.  I've been thinking about generalizing
the idea of child nodes to XPath expressions using the current element
as context.

Taking
http://stackoverflow.com/questions/23752354/xmlunit-recursiveelementnameandtextqualifier-not-working
as example one could use something like

    byXPath(".//a", byNameAndText)

and apply that to "td" and "tr" elements.  The corresponding selector
would run the Nodes returned by evaluating the XPath through a
comparison process and match the elements if all nodes returned could be
matched.

But I'm not sure this really is easy enough to understand and I'm afraid
it would become repetitive.  So a better idea is more than welcome.

Also ElementSelector only receives Elements as context, therefore the
big brother of selectorForElementNamed - conditionalSelector - works
with a Predicate<Element> to see whether it should apply.  This may be
cumbersome and I can easily see problems where the element name is not
enough and I need to know where the element is, something like the
XPathContext would be helpful.  This might require a change to the
ElementSelector and likely the NodeMatcher APIs.  Any ideas?

Stefan

Re: [Xmlunit-general] ComparisonControllers.StopWhenSimilar

[Stefan B. <bo...@ap...>]

Hi Harald

On 2015-02-07, Harald Brabenetz wrote:

> For the CompareMatcher I need also a
> ComparisonControllers.StopWhenSimilar implementation:
> https://github.com/brabenetz/xmlunit/commit/8bbda11263c1385ee97876235c4f1de63babe05e
> Let me know what you think. I will then create a separate pull
> request.

Sounds reasonable.

> I think the Hamcrest CompareMatcher should always stop the comparison
> depending on "checkForIdentical()" or "checkForSimilar()".  I think a
> public method like ".withComparisonController()" is only confusing for
> the Hamcrest CompareMatcher.

Yes, this is probably correct.  For the matcher the
isIdentical/SimilarTo methods cover the use cases of what you'd do with
a custom ComparisonController otherwise.

Stefan

[Xmlunit-general] ComparisonControllers.StopWhenSimilar

[Harald B. <bra...@gm...>]

Hi,

For the CompareMatcher I need also a ComparisonControllers.StopWhenSimilar implementation:
https://github.com/brabenetz/xmlunit/commit/8bbda11263c1385ee97876235c4f1de63babe05e
Let me know what you think. I will then create a separate pull request.

I think the Hamcrest CompareMatcher should always stop the comparison depending on "checkForIdentical()" or "checkForSimilar()". 
I think a public method like ".withComparisonController()" is only confusing for the Hamcrest CompareMatcher.

thanks,
Harald

[Xmlunit-general] Cleaned Up DifferenceEngine

[Stefan B. <bo...@ap...>]

Hi

when I added ComparisonController I used Map.Entry as a quick hack, this
has now been cleaned up a little in a branch named
diff-engine-alternative (both in xmlunit and xmlunit.net).  I'd
appreciate a quick review of the changes.

Stefan

[Xmlunit-general] Builder Package and some Naming Doubts

[Stefan B. <bo...@ap...>]

Hi all

currently we've got a builder package that bundles classes by their
technical role (they are fluent builders) rather than the API they
belong to.  I've started to wonder whether the concrete builders should
better live in the respective API packages (under different names,
likely).

Also I've realized I'm having a hard time to name things around the diff
package.  The single step the DifferenceEngine performs is a Comparison,
but what is the sum of all those Comparisons?  You can see the problem
in the name of the ComparisonController's stopDiffing method - so is
"diffing" what the DifferenceEngne does?  And is Diff really the best
name for the overall result?

I've always been notoriously bad at naming, maybe anybody else has a
better approach?

Stefan

[Xmlunit-general] DiffBuilder has landed in XMLUnit for .NET

[Stefan B. <bo...@ap...>]

Hi

.NET and Java are now on the same level again, while porting the rest
I've also made a few changes to the Java version.

* Diff#getDifferences returns Iterable rather than Iterator now

* DiffBuilder#withComparisonListeners used to add the listeners as
  DifferenceListeners rather than ComparisonListeners, I've changed that
  and added withDifferenceListeners.

Stefan

[Xmlunit-general] ported ComparisonFormatter to .NET

[Stefan B. <bo...@ap...>]

Hi

I've started to port Harald's latest pull request and while going
through the code I made a few adaptions.

The not quite cosmetic ones are

* I renamed DifferenceEvaluators#sequence to chain

* I made sure we use a controlled locale when using String#toLower

The later really fixes a bug waiting to be found on Turkish/Azeri
locales.  Harald, if you've got string feelings about the first one,
please yell.

Stefan

Re: [Xmlunit-general] ComparisonController

[Stefan B. <bo...@ap...>]

Hello Harald

On 2015-01-28, Harald Brabenetz wrote:

> Sorry for the delay, but I caught a cold.

No need to be sorry, get well soon.

> I created now the pull request and travis finished the build just now:
> https://travis-ci.org/xmlunit/xmlunit/builds/48669954

Looks good, I've just merged it.  I'll need to port it over to
XMLUnit.NET (which may well need to wait for the wekend to happen) and
while I do so may decide to modify a few details.

Many thanks!

     Stefan

Re: [Xmlunit-general] ComparisonController

[Harald B. <bra...@gm...>]

Sorry for the delay, but I caught a cold.
I created now the pull request and travis finished the build just now:
https://travis-ci.org/xmlunit/xmlunit/builds/48669954

thanks,
Harald


> Gesendet: Montag, 26. Januar 2015 um 09:37 Uhr
> Von: "Stefan Bodewig" <bo...@ap...>
> An: "Harald Brabenetz" <bra...@gm...>
> Cc: xml...@li...
> Betreff: Re: [Xmlunit-general] ComparisonController
>
> On 2015-01-26, Harald Brabenetz wrote:
> 
> > Hi,
> 
> > I cleaned up the changes for DiffBuilder and ComparisonFormatter:
> > https://github.com/brabenetz/xmlunit/commit/04c195c62388b59023a6af28df1e54b106886f9c
> 
> > And applied the changes for the ComparisonController:
> > https://github.com/brabenetz/xmlunit/commit/3028db8eae60bc85dabd5e9bbe632f89ae08afc9
> 
> Great.
> 
> > Is there something open?
> 
> There might be details I'd tackle in a different way myself, but nothing
> that is worth delaying this any further.  We can always hash it out
> later.
> 
> Thank you for your patience and persistence
> 
>       Stefan
> 

Re: [Xmlunit-general] ComparisonController

[Stefan B. <bo...@ap...>]

On 2015-01-26, Harald Brabenetz wrote:

> Hi,

> I cleaned up the changes for DiffBuilder and ComparisonFormatter:
> https://github.com/brabenetz/xmlunit/commit/04c195c62388b59023a6af28df1e54b106886f9c

> And applied the changes for the ComparisonController:
> https://github.com/brabenetz/xmlunit/commit/3028db8eae60bc85dabd5e9bbe632f89ae08afc9

Great.

> Is there something open?

There might be details I'd tackle in a different way myself, but nothing
that is worth delaying this any further.  We can always hash it out
later.

Thank you for your patience and persistence

      Stefan

Re: [Xmlunit-general] ComparisonController

[Harald B. <bra...@gm...>]

Hi,

I cleaned up the changes for DiffBuilder and ComparisonFormatter:
https://github.com/brabenetz/xmlunit/commit/04c195c62388b59023a6af28df1e54b106886f9c

And applied the changes for the ComparisonController:
https://github.com/brabenetz/xmlunit/commit/3028db8eae60bc85dabd5e9bbe632f89ae08afc9

Is there something open?
I will then squash the changes to one pull request and start with the Matcher.

with friendly regards,
Harald


> Gesendet: Samstag, 24. Januar 2015 um 19:46 Uhr
> Von: "Stefan Bodewig" <bo...@ap...>
> An: "Harald Brabenetz" <bra...@gm...>
> Cc: xml...@li...
> Betreff: Re: [Xmlunit-general] ComparisonController
>
> On 2015-01-24, Harald Brabenetz wrote:
> 
> >> I've moved the shared test resources to a separate repository. This
> >> means you need to run "git submodule update --init" once inside your
> >> working copies after merging github's master branches of xmlunit or
> >> xmlunit.net.
> 
> > Thanks, something new for me.
> > A little bit like "svn:externals" in svn.
> 
> Well, it is not as simple as svn:externals, but I guess the way we use
> it in XMLUnit is very similar to externals.
> 
> >> I've created a branch in order to experiment with separating the "do we
> >> want to stop comparing" functionality from "how severe is this
> >> difference".
> >> https://github.com/xmlunit/xmlunit/compare/ComparisonController
> 
> > looks really great! I can't wait to update the DiffBuilder.
> 
> Thanks, I merged the branch.
> 
> I'll port it over to .NET and the next bigger step will be experimenting
> with a clean implementation for DOMDifferenceEngine, one that doesn't
> look as ad hoc.
> 
> Stefan
> 

Re: [Xmlunit-general] ComparisonController

[Stefan B. <bo...@ap...>]

On 2015-01-24, Harald Brabenetz wrote:

>> I've moved the shared test resources to a separate repository. This
>> means you need to run "git submodule update --init" once inside your
>> working copies after merging github's master branches of xmlunit or
>> xmlunit.net.

> Thanks, something new for me.
> A little bit like "svn:externals" in svn.

Well, it is not as simple as svn:externals, but I guess the way we use
it in XMLUnit is very similar to externals.

>> I've created a branch in order to experiment with separating the "do we
>> want to stop comparing" functionality from "how severe is this
>> difference".
>> https://github.com/xmlunit/xmlunit/compare/ComparisonController

> looks really great! I can't wait to update the DiffBuilder.

Thanks, I merged the branch.

I'll port it over to .NET and the next bigger step will be experimenting
with a clean implementation for DOMDifferenceEngine, one that doesn't
look as ad hoc.

Stefan

Re: [Xmlunit-general] ComparisonController

[Harald B. <bra...@gm...>]

Hi,

> sorry for the radio silence, "real life" interfered in an urgent way.
> I'll look at your code and come back to you.
There is no Timeline :)
you already wrote it: It must be fun!

> DifferenceEvaluators.Default mandates a certain sense of similarity like
> TEXT and CDATA nodes of the same content are similar. I can envision
> use-cases where this doesn't match my expectation at all. This is
> especially true for differences in the order of child nodes which is
> also SIMILAR by default. If we always throw in DE.Default we impose
> this particular world view on all tests.
> > Even this rare cases could simply be handled with a method ".deactivateDefaultDifferenceEvaluator()"
> Maybe, I'm not completely convinced. :-)
You convinced me, I will update my code.

> Maybe I'm misunderstanding what SimpleIgnoreNodesDifferenceEvaluator
> would do. The missing feature I talk about is a way to say "I'm not
> interested in any differences between the sub-trees /x/y/z of the
> documents". This is not anything I'd like to add to DifferenceEvaluator
> but rather provide as a new extension point DifferenceEngine needs to
> provide.

Thanks, now I understand what you mean.
I was not thinking to ignore a whole tree.
In my cases, it was always enough to ignore a simple Text-Element
or Attribute: a generated UUID, a date-time element or a version number.
Nice point!

> I've moved the shared test resources to a separate repository. This
> means you need to run "git submodule update --init" once inside your
> working copies after merging github's master branches of xmlunit or
> xmlunit.net.

Thanks, something new for me.
A little bit like "svn:externals" in svn.

> I've created a branch in order to experiment with separating the "do we
> want to stop comparing" functionality from "how severe is this
> difference".
> https://github.com/xmlunit/xmlunit/compare/ComparisonController

looks really great! I can't wait to update the DiffBuilder.

Harald

[Xmlunit-general] ComparisonController

[Stefan B. <bo...@ap...>]

Hi

I've created a branch in order to experiment with separating the "do we
want to stop comparing" functionality from "how severe is this
difference".

https://github.com/xmlunit/xmlunit/compare/ComparisonController

The implementation in DifferenceEngine using Map.Entry is just a quick
hack, I didn't want to distract from the API change by refactoring
DifferenceEngine.

To me it feels cleaner to have them separate, it removed some clumsy
workarounds in DOMDifferenceEngineTest where a custom
DifferenceEvaluator delegated to DefaultStopWhenDifferent - of course at
the expense of other workarounds (the wrap methods).

The code in legacy's NewDifferenceEngine looks cleaner as well.

Stefan

Re: [Xmlunit-general] xmlunit.org

[Stefan B. <bo...@ap...>]

Hi

I'll try to come up with a branch that splits "stop diffing" out of the
"this is the comparison's result" logic of DifferenceEvaluator.  I'm
going to borrow your Difference class for this.

On 2015-01-18, Harald Brabenetz wrote:

> All changes for implementing DiffBuilder and ComparisonFormatter so far:
> https://github.com/brabenetz/xmlunit/commit/f4408ea23eca8afaff28b5b11dfea6bc67735f4e

I'd use DefaultComparisonFormatter rather than
ComparisonFormatterDefault, cosmetics.  I better stop quibbling about
details.

> "DifferenceEvaluators.sequence(...)" (I has updated the DifferenceEvaluatorsTest in the next commit):
> https://github.com/brabenetz/xmlunit/commit/cd88ac571d72582451a59f21b7a8cdffbff8b903

Looks good, I'd only have issues with naming (in particular of the test
case ;-)

> DiffBuilder.withDifferenceEvaluators(...) and withDifferenceEvaluators.deactivateDefaultDifferenceEvaluator():
> https://github.com/brabenetz/xmlunit/commit/f05706c13a4d4a19602857b052971bb865f5ae06

Not sure about the NOTHING evaluator.  Maybe it would be better to throw
an exception if the user disabled the default evaluator and did not
provide a DifferenceEvaluator explicitly.

Cheers

        Stefan

[Xmlunit-general] [ANN] XMLUnit 2.x Development Moved to GitHub

[Stefan B. <bo...@ap...>]

We are actively working on a re-designed XMLUnit which will be available
for both Java and .NET with a similar API.  Development of this version
has moved to a GitHub organization [1] with two git repositories for
Java and .NET respectively.

All discussion about XMLUnit independent of any version will happen on
the XMLUnit general mailing list [2].

XMLUnit for Java 1.x will still be maintained using the Sourceforge
infrastructure that has served as well for many years.

We don't intend to maintain XMLUnit for .NET 0.x any longer.

[1] https://github.com/xmlunit
[2] https://sourceforge.net/p/xmlunit/mailman/xmlunit-general/

[Xmlunit-general] test-resources are in a submodule now

[Stefan B. <bo...@ap...>]

Hi all

I've moved the shared test resources to a separate repository.  This
means you need to run "git submodule update --init" once inside your
working copies after merging github's master branches of xmlunit or
xmlunit.net.

Cheers

        Stefan

Re: [Xmlunit-general] DifferenceEvaluators (was xmlunit.org)

[Stefan B. <bo...@ap...>]

Hi Harald,

sorry for the radio silence, "real life" interfered in an urgent way.
I'll look at your code and come back to you.

On 2015-01-17, Harald Brabenetz wrote:

> Hi,

> I have a few questions about the DifferenceEvaluators:

>>> But I think that one DifferenceEvaluator is not enough.
>>> At least DifferenceEvaluators.Default should always be part of,
>>> otherwise there is no ComparisonResult.SIMILAR.

>> IMHO this is something the user of the API should take care of. If they
>> want to have DEFAULT's behaviour then they should include it explicitly.

> You think, that the code should look like the following?:
> ----------
> Diff myDiff = DiffBuilder.compare(control).withTest(test)
> 		.withDifferenceEvaluator(DifferenceEvaluators.first(
> 			DifferenceEvaluators.Default,
> 			new IgnoreAttributeDifferenceEvaluator("attr")))
> 		.checkForSimilar()
> 		.build();
> ----------

Probably, yes.

> But checkForSimilar() makes no sense without "DifferenceEvaluators.Default".

DifferenceEvaluators.Default mandates a certain sense of similarity like
TEXT and CDATA nodes of the same content are similar.  I can envision
use-cases where this doesn't match my expectation at all.  This is
especially true for differences in the order of child nodes which is
also SIMILAR by default.  If we always throw in DE.Default we impose
this particular world view on all tests.

>   Even this rare cases could simply be handled with a method ".deactivateDefaultDifferenceEvaluator()"

Maybe, I'm not completeley convinced. :-)

> I checked in the UnitTest:
> https://github.com/brabenetz/xmlunit/commit/4a8e5eb676809344a6dbaf814289a6495db80728

>>> But then I need a method like DifferenceEvaluators.inSequence(...)
>>> instead of DifferenceEvaluators.first(...).

>> first() picks the first that changes the outcome, what would be the
>> result of inSequence()?

> Simply passes the result to the next evaluator.

OK, understood.  "chained" rather than "inSequence"?

>>> I also think about a general SimpleIgnoreNodesDifferenceEvaluator
>>> (ignore some nodes) or a SimpleBigDecimalNodesDifferenceEvaluator
>>> (which evaluates "1" similar "1.00") implementations.

>> The first one hints at the missing feature of ignoring parts completely.
>> I don't think DifferenceEvaluator is the best place for this. The
>> second one sounds like a third jar of xmlunit-library rather than -core?

> Yes, it could be a third jar of xmlunit-library.

ACK

> What you mean with "DifferenceEvaluator is not the best place for
> this"? Is there another way?

Maybe I'm misunderstanding what SimpleIgnoreNodesDifferenceEvaluator
would do.  The missing feature I talk about is a way to say "I'm not
interested in any differences between the sub-trees /x/y/z of the
documents".  This is not anything I'd like to add to DifferenceEvaluator
but rather provide as a new extension point DifferenceEngine needs to
provide.

Stefan