Hi Christian,
Yes, I already learned to write tests to work around not being able to compare maps. It was more the general behaviour of a test run not giving me much to go on. Noticed it on maps mainly.
Thanks for the tip of piping result through an expression, didn't think of that.
Keep up the good work, I'm generally enjoying this :)
--Marc
On Wed, Jul 30, 2014 at 4:48 PM, Christian Grün christian.gruen@gmail.com wrote:
Hi Marc,
I regret that I'm not able to get down into the guts of the Java code and help fix it, so, instead I moan ;-)
Thanks for moaning! XQUnit is still sth. we are heavily working on, so any feedback is welcome.
- assertions causing an NPE when an XQuery error is raised but no
traceback
that tells me what/where the error actually is. [ex1]
NPEs are usually serious bugs. We'll have a look at that.
- assertions causing a failure/error reported, produce a test result but
stop running further tests after the one that raises the error [ex2]
The reason is that maps are functions, and functions cannot be compared. But the current version of the XQuery spec. will provide support for comparing maps, so it's basically a matter of time when the comparision of maps will be made possible. I'll dig into this one as well; maybe it's not a big deal to provide an early yet stable implementation.
- Personally, I run the tests often (minutes rather than hours), and from
the shell. The XML format feedback isn't very helpful.
It's probably not that trivial to find a proper textual representation for everything that can be done with XQUnit. One thing you can do is to send the output to a second BaseX call. The following command-line code will only return the failures of your XML code:
basex -t . | basex -i - //failure
Of course, you could also call a function that does some more sophisticated stuff with your input.
Hope this helps, Christian