Damian wrote: ... > Go for it. It is done. (Revision 17044.)
> Although I have to say that after some problems we had with > XML unit on IBM JVM Kevin and I were on the verge of removing > it entirely in favor of simple String comparisons. Some tests > were randomly failing and we never found out way. Kevin lost > couple of days chasing it and then it stopped as inexplicably > as it started. When was this? We were updated to the latest IBM JVM a few months ago, so things might be better now. (Hard to tell though if the problem isn't reproducible.) > Especially if you run the tests in Eclipse side by side view > works much better than cryptic XPath expression telling you > where the problem is. To me the big advantage of an XML compare is that you don't need to keep expected and generated character-for-character synchronized. The problem output will be a lot more useful now. (Part of what I needed xmlunit-1.3 for.) Suppose the generated file contains an unexpected Polycom property. Previously you would only see: [different] Expected number of element attributes '13' but was '14' - comparing <SIP...> at /sip[1]/voIpProt[1]/SIP[1] to <SIP...> at /sip[1]/voIpProt[1]/SIP[1] Now you will also see: [different] Expected attribute name 'null' but was 'voIpProt.SIP.use486forReject' - comparing <SIP...> at /sip[1]/voIpProt[1]/SIP[1] to <SIP...> at /sip[1]/voIpProt[1]/SIP[1] -Paul [email protected] _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
