Menu
▾
▴
xmlunit-general
|
From: Harald B. <bra...@gm...> - 2015-01-16 23:27:31
|
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();
----------
I think "checkForSimilar" will be the preferred method to compare two XMLs.
But checkForSimilar() makes no sense without "DifferenceEvaluators.Default".
On the other site I can't think of a situation where the "DifferenceEvaluators.Default" must be ignored to get a special goal?
Even this rare cases could simply be handled with a method ".deactivateDefaultDifferenceEvaluator()"
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.
Reason: The custom DifferenceEvaluator should also be triggered (e.g.: for Ignore) even if a Node was marked as "similar" before.
And maybe the custom DifferenceEvaluator want to check if the Difference was "similar".
>> 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.
What you mean with "DifferenceEvaluator is not the best place for this"? Is there another way?
Thanks,
Harald
|
|
From: Stefan B. <ste...@fr...> - 2014-12-28 04:56:14
|
[looks as if there has been some kind of hickup yesterday] From: Stefan Bodewig <bo...@ap...> To: "Harald Brabenetz" <bra...@gm...> Cc: xml...@li... Subject: Re: [Xmlunit-general] xmlunit.org References: <87b...@v3...> <trinity-71edbf3b-e880-4568-a6d7-c90c9d574357-1419445946480@3capp-gmx-bs51> <trinity-85875985-0f2a-4f29-901b-c68374c7a436-1419615896466@3capp-gmx-bs51> Date: Fri, 26 Dec 2014 19:01:38 +0100 In-Reply-To: <trinity-85875985-0f2a-4f29-901b-c68374c7a436-1419615896466@3capp-gmx-bs51> (Harald Brabenetz's message of "Fri, 26 Dec 2014 18:44:56 +0100") Message-ID: <87m...@v3...> On 2014-12-26, Harald Brabenetz wrote: > I made the first working draft: > https://github.com/brabenetz/xmlunit > checkout and "mvn install" works fine with unit-tests. I'll take a look at it soon, not sure whether I'll get there today, thanks! Not sure whether you've received my response I sent to the list (I don't see it inside the archives, yet). > I changed the groupId to "org.xmlunit" (according to the new homepage) Sounds right. > If this is OK for you, I will release an alpha release "2.0-alpha1" to > test the release plugin (and all depending parts like Sonatype, > GitHub). I'd sincerly hope Sonatype won't let you push artifacts to the org.xmlunit groupId, at least not yet. Currently I've got the privileges to push to xmlunit and wanted to obtain them for org.xmlunit soon. Content wise I don't feel we are ready for an alpha release, but would be fine with SNAPSHOTs. Those should be created from the main xmlunit repository, of course. Cheers Stefan |
|
From: Stefan B. <bo...@ap...> - 2014-12-29 05:54:23
|
[looks as if sourceforge's infra is undergoing serious problems, their SMTP server is denying connections because it's under too big a load and when I tried to report the problem via the issue tracker I received a server error page] On 2014-12-27, Stefan Bodewig wrote: > On 2014-12-26, Harald Brabenetz wrote: >> I made the first working draft: >> https://github.com/brabenetz/xmlunit >> checkout and "mvn install" works fine with unit-tests. > I'll take a look at it soon, not sure whether I'll get there today, > thanks! Again, many thanks Harald. Before you put any more effort into it, let's try to figure out what we really need. I think we should inherit from Sonatype's OSS parent which will immediately give us a lot of stuff you've put into the profile and pluginManagement. I'd like to have xmlunit-core use the artifactId xmlunit-core and I'm pretty sure it doesn't need JUnit at compile time. The Ant build currently creates xmlunit-sumo that I intended as a drop-in replacement for xmlunit.jar of 1.x. It really just is the combined content of xmlunit-core and xmlunit-legacy, something we can probably achieve with some shading. Cheers Stefan |
|
From: Stefan B. <ste...@fr...> - 2014-12-28 06:45:52
|
[looks as if there has been some kind of hickup yesterday] From: Stefan Bodewig <bo...@ap...> To: xml...@li... Subject: Re: [Xmlunit-general] xmlunit.org References: <87b...@v3...> <trinity-71edbf3b-e880-4568-a6d7-c90c9d574357-1419445946480@3capp-gmx-bs51> Date: Fri, 26 Dec 2014 12:12:05 +0100 In-Reply-To: <trinity-71edbf3b-e880-4568-a6d7-c90c9d574357-1419445946480@3capp-gmx-bs51> (Harald Brabenetz's message of "Wed, 24 Dec 2014 19:32:26 +0100") Message-ID: <87o...@v3...> On 2014-12-24, Harald Brabenetz wrote: > I would like to provide the changes to a standard maven Project. Somehow I knew this would happen, I just didn't expect it to be the first thing that comes up :-) I could counter all of your arguments with a "it's not a problem for me". For example xmlunit 1.x is in maven central, so I obviously know how to get it there without using the release plugin ;-) But I'm willing to accept that my view of the world is not shared by too many people. So I may switch to using Maven and a multi-module layout even though it would hurt me, but I'd *really* like to understand what the benefit for XMLUnit would be. To explain what I mean: when I started writing the user guide for XMLUnit for Java 1.x I've been talked into using docbook rather than LaTeX against my personal preferences (at least that's my recollection). In the end I never received a single contribution to the user guide and ended up using a system I didn't want to use. I'd prefer to not see the same happen again. I guess what I'm asking is: can I be sure there will be a result that goes beyond replacing a build system I like with one I don't like :-) Is there anything in particular you'd want to work on? > There is "maybe" only one Problem: > I have no clue how the .Net part works. Which shows a totally different but real problem. I cannot expect people to be equally familiar with or even just interested in the Java and .NET implementations. It may be better to finally split the two implementations so contributors don't feel they have to contribute to both parts at the same time. Oh, the .NET part builds using NAnt, at least until anybody suggests to move to MSBuild/xbuild. Cheers Stefan |
|
From: Harald B. <bra...@gm...> - 2014-12-28 19:59:52
|
Hi,
I'm certain, that with maven it is easier to contribute to xmlunit.
The first time I checked out xmlunit I must do the following:
- search and add the source-folders to my project
- search and add the libraries to my project
- hope that I doesn't forgot something (in which case I must study the ANT script)
Also I doesn't got the Source/JavaDoc for JUnit and Hamecrest libraries
With Maven there is only one step after cloning the GIT-Repo:
- import project as Maven Project
And I get also the Sources and JavaDoc of the dependent libraries
This works for all modern IDEs like Eclipse, NetBeans, IntelliJ.
I understand you completely, if you don't want change anything without "real" contributions to the project :)
I would like to contribute a CompareMatcher with fluent style:
public final class MyProjectSpecificTestUtils {
public static CompareMatcher isSimilarTo(final File file) {
return new CompareMatcher(file)
.useDifferenceListener(createDifferenceListener())
.useElementQualifier(createElementQualifier());
}
...
}
The JUnitTests looks like the following:
// run test which returns a JaxB Object
final MyJaxbResponse jaxbResponse = callMyWebserviceImplementation("request.xml");
// validate result
assertThat(jaxbResponse, MyProjectSpecificTestUtils.isSimilarTo(getTestFile("expectedResponse.xml")));
But I must rewrite my code for the new XmlUnit-API (e.g.: use NodeMatcher instead ElementQualifier).
Is there a documentation for the new API?
What is the new Syntax for a comparission for "similar":
Diff myDiff = new Diff(myControlXML, myTestXML);
assertTrue("XML similar " + myDiff.toString(), myDiff.similar());
I found no default implementation of a ComparisonListener.java (only in tests and legacy).
with friendly regards,
Harald
> Gesendet: Samstag, 27. Dezember 2014 um 14:37 Uhr
> Von: "Stefan Bodewig" <ste...@fr...>
> An: xml...@li...
> Betreff: [Xmlunit-general] [RESEND] Re: xmlunit.org
>
> [looks as if there has been some kind of hickup yesterday]
>
> From: Stefan Bodewig <bo...@ap...>
> To: xml...@li...
> Subject: Re: [Xmlunit-general] xmlunit.org
> References: <87b...@v3...>
> <trinity-71edbf3b-e880-4568-a6d7-c90c9d574357-1419445946480@3capp-gmx-bs51>
> Date: Fri, 26 Dec 2014 12:12:05 +0100
> In-Reply-To: <trinity-71edbf3b-e880-4568-a6d7-c90c9d574357-1419445946480@3capp-gmx-bs51>
> (Harald Brabenetz's message of "Wed, 24 Dec 2014 19:32:26 +0100")
> Message-ID: <87o...@v3...>
>
> On 2014-12-24, Harald Brabenetz wrote:
>
> > I would like to provide the changes to a standard maven Project.
>
> Somehow I knew this would happen, I just didn't expect it to be the
> first thing that comes up :-)
>
> I could counter all of your arguments with a "it's not a problem for
> me". For example xmlunit 1.x is in maven central, so I obviously know
> how to get it there without using the release plugin ;-)
>
> But I'm willing to accept that my view of the world is not shared by too
> many people. So I may switch to using Maven and a multi-module layout
> even though it would hurt me, but I'd *really* like to understand what
> the benefit for XMLUnit would be.
>
> To explain what I mean: when I started writing the user guide for
> XMLUnit for Java 1.x I've been talked into using docbook rather than
> LaTeX against my personal preferences (at least that's my
> recollection). In the end I never received a single contribution to the
> user guide and ended up using a system I didn't want to use. I'd prefer
> to not see the same happen again.
>
> I guess what I'm asking is: can I be sure there will be a result that
> goes beyond replacing a build system I like with one I don't like :-)
>
> Is there anything in particular you'd want to work on?
>
> > There is "maybe" only one Problem:
> > I have no clue how the .Net part works.
>
> Which shows a totally different but real problem. I cannot expect
> people to be equally familiar with or even just interested in the Java
> and .NET implementations. It may be better to finally split the two
> implementations so contributors don't feel they have to contribute to
> both parts at the same time.
>
> Oh, the .NET part builds using NAnt, at least until anybody suggests to
> move to MSBuild/xbuild.
>
> Cheers
>
> Stefan
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Xmlunit-general mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlunit-general
>
|
|
From: Stefan B. <ste...@fr...> - 2014-12-28 21:41:24
|
On 2014-12-28, Harald Brabenetz wrote: > I'm certain, that with maven it is easier to contribute to xmlunit. Maybe. I'll think about it but don't promise anything. If we move things around to make Maven happy, this might be the best point in time to split the Java and .NET implementations. Which also requires a solution for the shared test resources (yet another repo and submodules or subtrees, likely). So please dont put too much effort into it now, we'd only end up with merge conflicts. My short term focus is getting XMLUnit Java 1.6 out. I've been working on https://sourceforge.net/p/xmlunit/bugs/65/ for a while and have uncovered two bugs in xmlunit-legacy while porting a not yet committed solution from XMLUnit 1.x - interesting. All this while juggling some real-live responsibilities, please bear with me. :-) > I would like to contribute a CompareMatcher with fluent style: This sounds great. > But I must rewrite my code for the new XmlUnit-API (e.g.: use > NodeMatcher instead ElementQualifier). I'd shoot for ElementSelector and DefaultNodeMatcher when replacing ElementQualifier. > Is there a documentation for the new API? Unfortunately nothing beyond Javadocs and the tests. I wanted to document the design ideas behind some parts of the new API in the Wiki and even discuss things there as I'm sure there are a few things that could be solved in a nicer way. > What is the new Syntax for a comparission for "similar": > Diff myDiff = new Diff(myControlXML, myTestXML); > assertTrue("XML similar " + myDiff.toString(), myDiff.similar()); Yet another missing piece. > I found no default implementation of a ComparisonListener.java (only > in tests and legacy). I'm not sure there is a default implementation that is of wider use. The sketch in my head that needs to get written down goes along the lines of Diff myDiff = DiffBuilder.compareControl(Input.fromMemory(myControlXML)) .withTest(Input.fromMemory(myTestXML)) .build(); assertTrue("XML similar " + myDiff.toString(), myDiff.isSimilar()); where DiffBuilder uses an internal implementation of ComparisonListener and turns the collected results into a(n imutable) Diff object which captures the outcome. The DiffBuilder would have additional methods for specifying custom NodeMatchers, DifferenceEvaluators and so on. I can easily see your ComparisonMatcher work on top of DiffBuilder. One thing that is important to me is to keep external dependencies - and JUnit is one - out of core. I can easily envision a graphical XML diff tool on top of DifferenceEngine that visualizes differences based on information obtained via ComparisonListener callbacks. Cheers Stefan |
|
From: Harald B. <bra...@gm...> - 2014-12-31 21:49:55
|
Hi, --------------------------- MAVEN --------------------------- I moved the Maven-Changes to a branch (So i can work in master-branch on the Diff, DiffMatcher and CompareMatcher): https://github.com/brabenetz/xmlunit/tree/2.0-maven-changes There are no big changes: moving some folders and creating the pom.xmls You can copy the pom.xmls from the branch. About the pom.xmls: - maven-release-plugin is not important for other contributors. I only added it because I think that it makes releases easier. Let me know if you want the pom.xmls without release-plugin, I will cleanup the pom.xmls in my branch. (than a release must be done manually by: update version, create Github-TAG, deploy to sonatype, update to next SNAPSHOT version). - pom.xml of xnlunit-legacy. I configured the "BSD 3-Clause License": http://opensource.org/licenses/BSD-3-Clause (it matches the header-texts) About the tests: - I changed the paths to "/test/" (Maven standard folder name) instead "/tests/", but better would be to add the test-dependencies of the core module and load the files from classpath. This would solve the problem with the shared test-resources. And not only for resources, I want add some Jaxb-Objects for some tests with javax.xml.bind.util.JAXBSource (e.g.: Input.fromJaxbObject(Object obj)) --------------------------- Diff & DiffBuilder --------------------------- > Diff myDiff = DiffBuilder.compareControl(Input.fromMemory(myControlXML)) > .withTest(Input.fromMemory(myTestXML)) > .build(); > assertTrue("XML similar " + myDiff.toString(), myDiff.isSimilar()); Thanks! That's exactally what I have searched for :) I will try to implement the Diff and DiffBuilder in xmmlunit-core. Can I move the isSimilar() method to the Builder (e.g.: DiffBuilder.checkForSimilar()). In case of similar-compare I'm not interested in all the "[not identical] ..." messages from the toString() method (this was a little irritating from XmlUnit 1.x). // Example: // (DiffBuilder-Default: collect ComparisonResult.SIMILAR, DIFFERENT and CRITICAL) Diff myDiff = DiffBuilder.compareControl(Input.fromMemory(myControlXML)) .withTest(Input.fromMemory(myTestXML)) .checkForSimilar() // collect only ComparisonResult.DIFFERENT and CRITICAL .build(); assertTrue("XML similar " + myDiff.toString(), myDiff.hasDifferences()); --------------------------- Legacy-Code --------------------------- I will also implement some of the old methods from XmlUnit with code like "new DiffBuilder().ignoreComments()". Are my assumptions correct?: XMLUnit.setIgnoreAttributeOrder() => 2.x will always ignore the attribute order, right? XMLUnit.setIgnoreComments() => use of "new CommentLessSource(...)" XMLUnit.setIgnoreDiffBetweenTextAndCDATA() => in 2.x already marked with ComparisonType.NODE_TYPE with ComparisonResult.SIMILAR (another behaviour would require a custom DifferenceEvaluator) XMLUnit.setIgnoreWhitespace() => use of "new WhitespaceStrippedSource(...)" XMLUnit.setNormalizeWhitespace => use of "new WhitespaceNormalizedSource(...)" --------------------------- Documentation --------------------------- If I'm finished with it, I will start the Wiki Pages: - "Writing XML comparison tests" (basically the updated documentation from 1.x "1.5. Writing XML comparison tests") + TestCase with a Diff instance + TestCase with a Hamcrest CompareMatcher + Example with DifferenceEvaluator + Example with NodeMatcher, DefaultNodeMatcher and NodeTypeMatcher happy new Year, Harald > Gesendet: Sonntag, 28. Dezember 2014 um 22:40 Uhr > Von: "Stefan Bodewig" <ste...@fr...> > An: xml...@li... > Cc: "Harald Brabenetz" <bra...@gm...> > Betreff: Re: [Xmlunit-general] [RESEND] Re: xmlunit.org > > On 2014-12-28, Harald Brabenetz wrote: > > > I'm certain, that with maven it is easier to contribute to xmlunit. > > Maybe. I'll think about it but don't promise anything. > > If we move things around to make Maven happy, this might be the best > point in time to split the Java and .NET implementations. Which also > requires a solution for the shared test resources (yet another repo and > submodules or subtrees, likely). So please dont put too much effort > into it now, we'd only end up with merge conflicts. > > My short term focus is getting XMLUnit Java 1.6 out. I've been working > on https://sourceforge.net/p/xmlunit/bugs/65/ for a while and have > uncovered two bugs in xmlunit-legacy while porting a not yet committed > solution from XMLUnit 1.x - interesting. > > All this while juggling some real-live responsibilities, please bear > with me. :-) > > > I would like to contribute a CompareMatcher with fluent style: > > This sounds great. > > > But I must rewrite my code for the new XmlUnit-API (e.g.: use > > NodeMatcher instead ElementQualifier). > > I'd shoot for ElementSelector and DefaultNodeMatcher when replacing > ElementQualifier. > > > Is there a documentation for the new API? > > Unfortunately nothing beyond Javadocs and the tests. I wanted to > document the design ideas behind some parts of the new API in the Wiki > and even discuss things there as I'm sure there are a few things that > could be solved in a nicer way. > > > What is the new Syntax for a comparission for "similar": > > Diff myDiff = new Diff(myControlXML, myTestXML); > > assertTrue("XML similar " + myDiff.toString(), myDiff.similar()); > > Yet another missing piece. > > > I found no default implementation of a ComparisonListener.java (only > > in tests and legacy). > > I'm not sure there is a default implementation that is of wider use. > > The sketch in my head that needs to get written down goes along the > lines of > > Diff myDiff = DiffBuilder.compareControl(Input.fromMemory(myControlXML)) > .withTest(Input.fromMemory(myTestXML)) > .build(); > assertTrue("XML similar " + myDiff.toString(), myDiff.isSimilar()); > > where DiffBuilder uses an internal implementation of ComparisonListener > and turns the collected results into a(n imutable) Diff object which > captures the outcome. The DiffBuilder would have additional methods for > specifying custom NodeMatchers, DifferenceEvaluators and so on. > > I can easily see your ComparisonMatcher work on top of DiffBuilder. > > One thing that is important to me is to keep external dependencies - and > JUnit is one - out of core. I can easily envision a graphical XML diff > tool on top of DifferenceEngine that visualizes differences based on > information obtained via ComparisonListener callbacks. > > Cheers > > Stefan > |
|
From: Stefan B. <ste...@fr...> - 2015-01-02 15:29:14
|
Happy new year, On 2014-12-31, Harald Brabenetz wrote: > I moved the Maven-Changes to a branch (So i can work in master-branch on the Diff, DiffMatcher and CompareMatcher): > https://github.com/brabenetz/xmlunit/tree/2.0-maven-changes Good. > --------------------------- > Diff & DiffBuilder > --------------------------- >> Diff myDiff = DiffBuilder.compareControl(Input.fromMemory(myControlXML)) >> .withTest(Input.fromMemory(myTestXML)) >> .build(); >> assertTrue("XML similar " + myDiff.toString(), myDiff.isSimilar()); > Thanks! That's exactally what I have searched for :) I should be able to write down my design ideas in the wiki this coming weekend, feel free to comment there and show me where I went wrong while designing in some kind of a vacuum. :-) > I will try to implement the Diff and DiffBuilder in xmmlunit-core. > Can I move the isSimilar() method to the Builder (e.g.: DiffBuilder.checkForSimilar()). > In case of similar-compare I'm not interested in all the "[not identical] ..." messages from the toString() method (this was a little irritating from XmlUnit 1.x). Well, Diff doesn't have to be the same as it is in 1.x, quite the opposite. Right now I'd say an overall result (maybe accessible via isSimilar/isDifferent) and an Iterable of Differences found would be all it takes. I haven't thought about the toString implementation so far. > --------------------------- > Legacy-Code > --------------------------- > I will also implement some of the old methods from XmlUnit with code > like "new DiffBuilder().ignoreComments()". If you think they are useful, yes. Otherwise people could always wrap their inputs in a CommentLessSource. > Are my assumptions correct?: > XMLUnit.setIgnoreAttributeOrder() => 2.x will always ignore the > attribute order, right? > XMLUnit.setIgnoreComments() => use of "new CommentLessSource(...)" > XMLUnit.setIgnoreDiffBetweenTextAndCDATA() => in 2.x already marked with ComparisonType.NODE_TYPE with ComparisonResult.SIMILAR (another behaviour would require a custom DifferenceEvaluator) > XMLUnit.setIgnoreWhitespace() => use of "new WhitespaceStrippedSource(...)" > XMLUnit.setNormalizeWhitespace => use of "new WhitespaceNormalizedSource(...)" yes, this is what I planned. > --------------------------- > Documentation > --------------------------- > If I'm finished with it, I will start the Wiki Pages: Great, please use the wiki inside the userguide repository. It should be writable for everybody. Cheers Stefan |
|
From: Stefan B. <bo...@ap...> - 2015-01-02 15:38:34
|
On 2015-01-02, Stefan Bodewig wrote: > On 2014-12-31, Harald Brabenetz wrote: >> I will also implement some of the old methods from XmlUnit with code >> like "new DiffBuilder().ignoreComments()". > If you think they are useful, yes. Otherwise people could always wrap > their inputs in a CommentLessSource. On second thought, no, I'd rather add this to the Input-Builder than the DiffBuilder. Stefan |
|
From: Stefan B. <bo...@ap...> - 2015-01-05 13:40:21
|
[even if it seems that your messages don't make it through, please keep the list in CC] On 2015-01-04, Harald Brabenetz wrote: > I think the DiffBuilder is the right place, because CommentLessSource, > WhitespaceStrippedSource, WhitespaceNormalizedSource makes mostly > sense if they are used on Control- and Test-Source in the same way. "the right place" for specifying, that you want to ignore comments? The argument that I'll have to treat boths inputs the same is compelling. > But the Input.Builder could have the same implementation (maybe by an > AbstractBuilder implementation?). > ------------- > Diff & DiffBuilder. > ------------- > I'm now finished with Diff & DiffBuilder. I'll try to have a look and provide feedback soon. > ------------- > Input > ------------- > Valid inputs for control and test are all Objects supported by > Input.fromUnknown(Object). >From the sound of it I'm not fond of fromUnknown but will first look at the code before commenting any further. > Also I implemented the Method Input.fromJaxb(Object) with the same > default marshaller rules from javax.xml.bind.JAXB (but with the > Input.Builder as Result). Ah, nice catch. Could you create a separate pull request just for the missing JAXBSource part? > ------------- > ComparisonFormatter => used in Diff.toString() > ------------- Again, I'll have to defer commenting until I've found time to look at the code. > I created UnitTestCases for each ComparisonType in > ComparisonFormatterDefaultTest. Only > ComparisonType.NO_NAMESPACE_SCHEMA_LOCATION I couldn't reproduce: I > got only ComparisonType.ATTR_VALUE: > Diff diff = DiffBuilder.compare( > "<a xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" " > + "xsi:noNamspaceSchemaLocation=\"Book.xsd\"/>", there is a typo in the attribute name - a missing "e" in Nam*e*space. Cheers Stefan |
|
From: Harald B. <bra...@gm...> - 2015-01-05 18:08:52
|
Hi, >> [even if it seems that your messages don't make it through, please keep the list in CC] sorry, I forgot. >> Input.fromUnknown(Object) It is in my branch: https://github.com/brabenetz/xmlunit/blob/master/src/main/java-core/org/xmlunit/builder/Input.java#L109 > I'll try to have a look and provide feedback soon. Thanks, today I will checkin the CompareMatcher implementation. > > Also I implemented the Method Input.fromJaxb(Object) .... > Ah, nice catch. Could you create a separate pull request just for the > missing JAXBSource part? difficult: I must create a separate branch and checkin the different features. I don't know how good the GIT-Merge of my master branch then works. Maybe I must copy manually all features to the new branch for there pull-requests. Maybe I can separate three Features/Pull-Requests: "Input.fromJaxb with JaxbBuilder", "Diff & DiffBuilder with ComparisonFormatter" (I used the DiffBuilder for the UnitTests of the ComparisonFormatter), "CompareMarshaller" Easier would be one pull request all together from my master branch. ------------- Nice Diff-View with org.junit.ComparisionFailure. ------------- Can I add junit 4 library to xmlunit-hamecrest? I think it's only optional: It will not throw a ClassCastException if the following feature (CompareMatcher.throwComparisonFailure()) is not used. I added a Sceencast and Screenshot as attachement. The CompareMatcher could also be used to throw an org.junit.ComparisionFailure. Eclipse can open a nice Diff-View of the two nodes (see Screencast). IntelliJ should also have this feature: https://youtrack.jetbrains.com/issue/IDEA-57880 Also NetBeans: http://wiki.netbeans.org/NewAndNoteWorthyNB67#JUnit_Integration The syntax is like: assertThat(testSource, CompareMatcher.isSimilar(controlSource).throwComparisonFailure()); with friendly regards, Harald > Gesendet: Montag, 05. Januar 2015 um 14:39 Uhr > Von: "Stefan Bodewig" <bo...@ap...> > An: "Harald Brabenetz" <bra...@gm...> > Cc: xml...@li... > Betreff: Re: xmlunit.org > > [even if it seems that your messages don't make it through, please keep > the list in CC] > > On 2015-01-04, Harald Brabenetz wrote: > > > I think the DiffBuilder is the right place, because CommentLessSource, > > WhitespaceStrippedSource, WhitespaceNormalizedSource makes mostly > > sense if they are used on Control- and Test-Source in the same way. > > "the right place" for specifying, that you want to ignore comments? The > argument that I'll have to treat boths inputs the same is compelling. > > > But the Input.Builder could have the same implementation (maybe by an > > AbstractBuilder implementation?). > > > ------------- > > Diff & DiffBuilder. > > ------------- > > I'm now finished with Diff & DiffBuilder. > > I'll try to have a look and provide feedback soon. > > > ------------- > > Input > > ------------- > > Valid inputs for control and test are all Objects supported by > > Input.fromUnknown(Object). > > From the sound of it I'm not fond of fromUnknown but will first look at > the code before commenting any further. > > > Also I implemented the Method Input.fromJaxb(Object) with the same > > default marshaller rules from javax.xml.bind.JAXB (but with the > > Input.Builder as Result). > > Ah, nice catch. Could you create a separate pull request just for the > missing JAXBSource part? > > > ------------- > > ComparisonFormatter => used in Diff.toString() > > ------------- > > Again, I'll have to defer commenting until I've found time to look at > the code. > > > I created UnitTestCases for each ComparisonType in > > ComparisonFormatterDefaultTest. Only > > ComparisonType.NO_NAMESPACE_SCHEMA_LOCATION I couldn't reproduce: I > > got only ComparisonType.ATTR_VALUE: > > Diff diff = DiffBuilder.compare( > > "<a xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" " > > + "xsi:noNamspaceSchemaLocation=\"Book.xsd\"/>", > > there is a typo in the attribute name - a missing "e" in Nam*e*space. > > Cheers > > Stefan > |
|
From: Stefan B. <bo...@ap...> - 2015-01-06 05:37:01
|
On 2015-01-05, Harald Brabenetz wrote: >>> Also I implemented the Method Input.fromJaxb(Object) .... >> Ah, nice catch. Could you create a separate pull request just for the >> missing JAXBSource part? > difficult: I must create a separate branch and checkin the different > features. I understand. In general I'd prefer finer grained PRs (even squashed to a single commit) as they are easier to review but I understand this is a problem to ask for them after the fact. Is all of the JAXB builder in the single commit https://github.com/brabenetz/xmlunit/commit/54923ce18be30aa340792a1e53dd420ff5e44a8a if so, I can easily pick just this one. >>> Input.fromUnknown(Object) > It is in my branch: > https://github.com/brabenetz/xmlunit/blob/master/src/main/java-core/org/xmlunit/builder/Input.java#L109 It is also inside the patch that introduced the JAXBBuilder. I understand the idea, maybe just "from" would be a better name - and I'd rather use a Map that a chain of instanceofs. One problem I see is how to interpret a String arg - you've decided to use fromMemory but fromFile or fromUri would also be legitimate choices. I guess I need to review the DiffBuilder stuff to understand how you intend to use it. Usually people will know what builder method they want to invoke :-) > ------------- > Nice Diff-View with org.junit.ComparisionFailure. > ------------- > Can I add junit 4 library to xmlunit-hamecrest? Please don't. I wouldn't want to introduce a JUnit dependency for users of TestNG which can also use Hamcrest matchers. > I think it's only optional: It will not throw a ClassCastException if > the following feature (CompareMatcher.throwComparisonFailure()) is not > used. The IDE visualization is certainly nice. An approach that might work is having an optional dependency and a fallback solution if ComparisonFailure is not there (like not throwing that exception and return false from matches). > I added a Sceencast and Screenshot as attachement. Thanks, this is helpful. Cheers Stefan |
|
From: Stefan B. <bo...@ap...> - 2015-01-06 08:04:47
|
On 2015-01-05, Stefan Bodewig wrote: >> ------------- >> Diff & DiffBuilder. >> ------------- >> I'm now finished with Diff & DiffBuilder. > I'll try to have a look and provide feedback soon. What I had in mind is slightly different, but not much. Let me explain what I would have done differently and we can then figure out together what seems to be the best. * Comparison is not good enough to capture a difference as the ComparisonResult is missing. So Diff should use a (new) class containing Comparison and outcome. * I hadn't thought of ComparisonFormatter but your IDE example is an intriguing one. My choice would be to have a toString method with a ComparisonFormatter argument rather than an instance variable. The no-arg toString would always use the default fomatter and ComparisonMatcher could pass in a different one when needed. * nit-pick I'd use Iterable rather than List as return value * I'd likely remove Diff#getFirstDifference completely * there can only be one DifferenceEvaluator, so the var-args versions are not needed - we may want to have a var-args withDifferenceListeners in DiffBuilder * DiffBuilder may want an option to short-cut the comparison as soon as the outcome is clear. I.e. return CRITICAL from the DifferenceEvaluator as soon as a DIFFERNT (or potentially a SIMILAR) result has been received. * my design would have ComparisonMatcher be a Matcher<Diff> and force people to create the Diff using DiffBuilder Diff diffResult = DiffBuilder... assertThat(diffResult, DiffMatcher.isSimilar()); that way we didn't have to duplicate ignoreWhitespace and friends in two or three builders. Maybe have a DiffMatcher and a ComparisonMatcher as separate classes with ComparisonMatcher being Matcher<Source>? This would also reduce the need for Input.fromUnknown. * DiffBuilder should be in the builder package While writing this list I've come to realize the DifferenceEvaluator contract is probably wrong. In order to short-cut a comparison it has to modify the comparison result. This likely means we need something akin to ComparisonController of 1.x. WDYT? Stefan |
|
From: Harald B. <bra...@gm...> - 2015-01-06 13:31:09
|
Hi, thanks for the quick review. > I understand. In general I'd prefer finer grained PRs (even squashed to > a single commit) as they are easier to review but I understand this is a > problem to ask for them after the fact. > Is all of the JAXB builder in the single commit > https://github.com/brabenetz/xmlunit/commit/54923ce18be30aa340792a1e53dd420ff5e44a8a Not everything. e.g.: JavaDoc and Input.fromUnknown returns a Source instead of a Builder. I will create a separate branch "XmlUnit_2.x_ready_to_push". > It is also inside the patch that introduced the JAXBBuilder. I > understand the idea, maybe just "from" would be a better name - and I'd > rather use a Map that a chain of instanceofs. I'm not sure if "instanceof" can be handled by a Map. > One problem I see is how to interpret a String arg - you've decided to > use fromMemory but fromFile or fromUri would also be legitimate choices. It's only a simple short-cut. Certainly, you can always use a Source/Builder by e.g.: Input.fromUri("..."). > I guess I need to review the DiffBuilder stuff to understand how you > intend to use it. Usually people will know what builder method they > want to invoke :-) Sure I know the input, but it makes my tests ugly :) I would more like to write: DiffBuilder.compare(control).withTest(test); then DiffBuilder.compare(Input.fromSomething(control)).withTest(Input.fromSomething(test)); I think that was the only indention for Input.fromUnknown(...) :) And there are no disadvantages. You can always use a Source or Input.Builder as input. > The IDE visualization is certainly nice. An approach that might work is > having an optional dependency and a fallback solution if > ComparisonFailure is not there (like not throwing that exception and > return false from matches). I could create the ComparisonFailure by reflections only if it exists. Then, not even the build-script to compile main/java-matcher will need the dependency. > * Comparison is not good enough to capture a difference as the > ComparisonResult is missing. So Diff should use a (new) class > containing Comparison and outcome. Yep, e.g. a "Difference.java" with Comparison and ComparisonResult as members. My second thought was: ComparisonResult will be per default CRITICAL (required for break up after first difference) > * I hadn't thought of ComparisonFormatter but your IDE example is an > intriguing one. My choice would be to have a toString method with a > ComparisonFormatter argument rather than an instance variable. The > no-arg toString would always use the default fomatter and > ComparisonMatcher could pass in a different one when needed. looks great > * nit-pick I'd use Iterable rather than List as return value No problem. > * I'd likely remove Diff#getFirstDifference completely But how? I need the first Difference to create a nice Exception-Message (or in Diff.toString()) > * there can only be one DifferenceEvaluator, so the var-args versions > are not needed - we may want to have a var-args > withDifferenceListeners in DiffBuilder withDifferenceListeners(): I forgot about that. I have not tested withDifferenceEvaluator() well enough. But I think that one DifferenceEvaluator is not enough. At least DifferenceEvaluators.Default should always be part of, otherweise there is no ComparisonResult.SIMILAR. But then I need a method like DifferenceEvaluators.inSequence(...) instead of DifferenceEvaluators.first(...). I also think about a general SimpleIgnoreNodesDifferenceEvaluator (ignore some nodes) or a SimpleBigDecimalNodesDifferenceEvaluator (which evaluates "1" similar "1.00") implementations. > * DiffBuilder may want an option to short-cut the comparison as soon as > the outcome is clear. I.e. return CRITICAL from the > DifferenceEvaluator as soon as a DIFFERNT (or potentially a SIMILAR) > result has been received. Like DifferenceEvaluators.stopWhenDifferent(...) but more like: DifferenceEvaluators.stopAt(ComparisonResult) => DiffBuilder.allDifferences(): return all differences (like now). Default is DifferenceEvaluators.stopAt(...) depending on checkFirstSimilar() or checkForIdentical() > * my design would have ComparisonMatcher be a Matcher<Diff> and force > people to create the Diff using DiffBuilder > Diff diffResult = DiffBuilder... > assertThat(diffResult, DiffMatcher.isSimilar()); > that way we didn't have to duplicate ignoreWhitespace and friends in > two or three builders. > Maybe have a DiffMatcher and a ComparisonMatcher as separate classes This feels not right: In this case the Matcher doesn't make the matching. A normal Matcher always contains the control Object to matching with. I'm not sure if "CompareMatcher extends DiffBuilder" makes sense only to avoid the delegate methods, but it could be a possibility. > with ComparisonMatcher being Matcher<Source>? > This would also reduce the need for Input.fromUnknown. Yes, would be no Problem, but it would made my tests a little bit uglier :) > * DiffBuilder should be in the builder package Thanks. --------------------- Summary --------------------- - I will crate a branch "XmlUnit_2.x_ready_to_push" with only the Input.fromJaxb(...). Later I will copy my other changes into this branch. - Input.fromUnknown(): I can rename or remove it. Let me know. - Create the ComparisonFailure by reflections if it exists (remove junit-dependency). - Create "Difference.java" with Comparison and ComparisonResult as members. - Create Diff.toString(ComparisonFormatter); - Diff.getDifferences() returns Iterator<Difference> - Add DiffBuilder.withDifferenceListeners(DifferenceListener...); - DiffBuilder.allDifferences(): default is DifferenceEvaluators.stopAt(...) depending on checkFirstSimilar() or checkForIdentical() - Move DiffBuilder into builder package But it could take a while. From now on, I have only time on weekends. The most of it I can do at the upcoming weekend. Cheers Harald |
|
From: Stefan B. <bo...@ap...> - 2015-01-06 15:27:28
|
On 2015-01-06, Harald Brabenetz wrote: >> Is all of the JAXB builder in the single commit >> https://github.com/brabenetz/xmlunit/commit/54923ce18be30aa340792a1e53dd420ff5e44a8a > Not everything. e.g.: JavaDoc and Input.fromUnknown returns a Source instead of a Builder. > I will create a separate branch "XmlUnit_2.x_ready_to_push". The best workflow is to create one branch per feature you want to contribute and create a pull request from that. After review you'd rebase the branch to a single commit (squash it) and I'll merge that commit. Of course this is cumbersome if you are working on several interdependent things at once and it may not always be possible, so we'll have to adjust. I prefer to have you make changes over me picking commits and modifying them as it will be easier for you to rebase your branches once the PR is merged this way. Also it will show you as the contributor more clearly. I hope this is not feeling like I was playing "fetch me a rock" with you, I very much appreciate your work and your patience. Thanks! >> It is also inside the patch that introduced the JAXBBuilder. I >> understand the idea, maybe just "from" would be a better name - and I'd >> rather use a Map that a chain of instanceofs. > I'm not sure if "instanceof" can be handled by a Map. The idea in Java8 code static Map<Class<?>, Function<?, Builder>> KNOWN_BUILDERS ... static { KNOWN_BUILDER.put(URI.class, u -> Input.fromUri((Uri) u)); } Builder from(Object source) { Function<?, Builder> f = KNOWN_BUILDERS.get(source.getClass()); return f == null ? f.apply(source) : fromJaxb(source); } of course the target is Java 1.6 so the "functions" will be anonymous inner classes and the static block will look ugly. >> One problem I see is how to interpret a String arg - you've decided to >> use fromMemory but fromFile or fromUri would also be legitimate choices. > It's only a simple short-cut. Certainly, you can always use a > Source/Builderby e.g.: Input.fromUri("..."). You could try to be smart and guess whether the String is an XML document (starts with a "<") or looks like an URI. I'm not sure it would be worth the effort, though. > I would more like to write: > DiffBuilder.compare(control).withTest(test); > then > DiffBuilder.compare(Input.fromSomething(control)).withTest(Input.fromSomething(test)); > I think that was the only indention for Input.fromUnknown(...) :) > And there are no disadvantages. You can always use a Source or > Input.Builder as input. Likely depends on how much you do with the "Source" in the rest of your tests, but I get your point. >> The IDE visualization is certainly nice. An approach that might work is >> having an optional dependency and a fallback solution if >> ComparisonFailure is not there (like not throwing that exception and >> return false from matches). > I could create the ComparisonFailure by reflections only if it exists. > Then, not even the build-script to compile main/java-matcher will need > the dependency. We'd better cache the reflection result in order to save runtime cost, though. Yes, that would be alternative to an optional dependency. >> * Comparison is not good enough to capture a difference as the >> ComparisonResult is missing. So Diff should use a (new) class >> containing Comparison and outcome. > Yep, e.g. a "Difference.java" with Comparison and ComparisonResult as > members. > My second thought was: ComparisonResult will be per default CRITICAL > (required for break up after first difference) I may want to look at the "SIMILAR" differences anyway? Or I may want to get all differences like 1.x's DetailedDiff. >> * I'd likely remove Diff#getFirstDifference completely > But how? I need the first Difference to create a nice > Exception-Message (or in Diff.toString()) differences.get(0) in toString? It just doesn't need to be public. > But I think that one DifferenceEvaluator is not enough. > At least DifferenceEvaluators.Default should always be part of, > otherweise 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 behavior then they should include it explicitly. > 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()? > 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? >> * my design would have ComparisonMatcher be a Matcher<Diff> and force >> people to create the Diff using DiffBuilder >> Diff diffResult = DiffBuilder... >> assertThat(diffResult, DiffMatcher.isSimilar()); >> that way we didn't have to duplicate ignoreWhitespace and friends in >> two or three builders. >> Maybe have a DiffMatcher and a ComparisonMatcher as separate classes > This feels not right: In this case the Matcher doesn't make the > matching. true >> with ComparisonMatcher being Matcher<Source>? >> This would also reduce the need for Input.fromUnknown. > Yes, would be no Problem, but it would made my tests a little bit > uglier :) understood. > - I will crate a branch "XmlUnit_2.x_ready_to_push" with only the > Input.fromJaxb(...). Later I will copy my other changes into this > branch. Since I'll merge your JAXB branch as soon as you open a pull request you better create a new branch for the rest ;-) > - Input.fromUnknown(): I can rename or remove it. Let me know. I'm not completely against including it. Others? > - Create the ComparisonFailure by reflections if it exists (remove junit-dependency). > - Create "Difference.java" with Comparison and ComparisonResult as members. > - Create Diff.toString(ComparisonFormatter); > - Diff.getDifferences() returns Iterator<Difference> > - Add DiffBuilder.withDifferenceListeners(DifferenceListener...); > - DiffBuilder.allDifferences(): default is DifferenceEvaluators.stopAt(...) depending on checkFirstSimilar() or checkForIdentical() > - Move DiffBuilder into builder package Thanks. > But it could take a while. From now on, I have only time on weekends. > The most of it I can do at the upcoming weekend. I'm not sure about my time constraints either, this is just your normal "I do work I find time for it and want to do so" pattern of open source. Don't feel obligated to do anything, this is supposed to be fun. As next steps I want to add a bit of javadocs and publish them from the xmlunit.org website and after that start migrating things (i.e. the Java part) to Maven. Stefan |
|
From: Harald B. <bra...@gm...> - 2015-01-18 10:14:18
|
Hi, for better Explanations, here are my checkins: All changes for implementing DiffBuilder and ComparisonFormatter so far: https://github.com/brabenetz/xmlunit/commit/f4408ea23eca8afaff28b5b11dfea6bc67735f4e "DifferenceEvaluators.sequence(...)" (I has updated the DifferenceEvaluatorsTest in the next commit): https://github.com/brabenetz/xmlunit/commit/cd88ac571d72582451a59f21b7a8cdffbff8b903 DiffBuilder.withDifferenceEvaluators(...) and withDifferenceEvaluators.deactivateDefaultDifferenceEvaluator(): https://github.com/brabenetz/xmlunit/commit/f05706c13a4d4a19602857b052971bb865f5ae06 Let me know what you think, I will merge all you want together for a single push request. with friendly regards, Harald > Gesendet: Samstag, 17. Januar 2015 um 00:27 Uhr > Von: "Harald Brabenetz" <bra...@gm...> > An: "Stefan Bodewig" <bo...@ap...>, xml...@li... > Betreff: Re: [Xmlunit-general] xmlunit.org > > > 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(); > ---------- > I think "checkForSimilar" will be the preferred method to compare two XMLs. > But checkForSimilar() makes no sense without "DifferenceEvaluators.Default". > On the other site I can't think of a situation where the "DifferenceEvaluators.Default" must be ignored to get a special goal? > Even this rare cases could simply be handled with a method ".deactivateDefaultDifferenceEvaluator()" > > 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. > Reason: The custom DifferenceEvaluator should also be triggered (e.g.: for Ignore) even if a Node was marked as "similar" before. > And maybe the custom DifferenceEvaluator want to check if the Difference was "similar". > > > >> 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. > What you mean with "DifferenceEvaluator is not the best place for this"? Is there another way? > > > Thanks, > Harald > > ------------------------------------------------------------------------------ > 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 > Xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlunit-general > |
|
From: Stefan B. <bo...@ap...> - 2015-01-23 13:28:43
|
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 |
|
From: Stefan B. <bo...@ap...> - 2015-01-20 11:39:55
|
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
|
