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 ;-)

No, seriously, here are a few more general things that bug me about the Unit module.

- assertions causing an NPE when an XQuery error is raised but no traceback that tells me what/where the error actually is. [ex1]

- assertions causing a failure/error reported, produce a test result but stop running further tests after the one that raises the error [ex2]

I tried to reduce these issues into a short example but I think that they highlight a more general issue with the current Unit module.

It's mainly the fact that there's no indication of the problem that forces me to add unit:ignore to all tests and one by one removing it, or executing the assertion xquery in a client to find out where the issue lies.

I also have an improvement idea:

- Personally, I run the tests often (minutes rather than hours), and from the shell. The XML format feedback isn't very helpful. It would be for automated test reports but I think the usability (readability) of the feedback during development is just as, if not more, important. Maybe adding an extra switch (-t for textual feedback and -tx for XML feedback) could help. It should just focus on summarizing clearly the expected, return values, failures and errors, and provide helpful context.

Note that I always run the code using `basex -t` from bash and I'm running 8.0 beta 7ba9510

Note too that most of these things happen to me when doing map related stuff.

... and now I stop moaning and get back to coding.

--Marc

[ex1] example of test that causes an NPE without any helpful output

declare %unit:test function test:npe() {
    unit:assert-equals(map {}('x'), map { 'x': 1 }('x'))
};

[ex2] example of test that causes further tests to be executed

declare %unit:test function test:fail() {
    unit:assert-equals(map {}, map { 'x': 1 })
};

doing

map {} = map {'x': 1} causes this error

 [XPTY0004] map(*) and map(*) cannot be compared.