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
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Xmlunit-general mailing list
Xmlunit-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xmlunit-general
