Adam Retter

I have a concern that your `test:fail` function is mixing concerns, it appears to do two things: 1. check that expected and actual match 2. log a failure message (conditionally...

> `test:fail` does not assert anything @adamretter > As you can clearly see in the provided example. The example isn't clear at all as it uses an assert library which...

Ah I see... It doesn't assert, however including them as args to test:fail, still mixes concerns and by extension limits the usefulness of test:fail. When I have a moment later...

Thanks Juri. I understand and I am generally in favour of this, I think it just needs a little tweaking and discussion

I think the full function signature for a `test:fail` function should look like: ```xquery test:fail($code as xs:QName?, $description as xs:string, $failure-object as item()*) as none ``` We can then also...

@line-o You still appear to have the old versions of `test:fail` which mix concerns (i.e. they still expect `actual` and `expected` values). Can you remove those please as they are...

@line-o The premise behind all of my concerns with this PR is that having actual and expected values as explicit arguments mixes concerns in a negative way! Instead, with my...

> both the actual and expected values can be sequences and will be mashed together into a single sequence making it impossible for later code to distinguish them That is...

I think there are some things here that still need to be discussed and developed further, I will try and find some time later in the week to take a...

> @adamretter can you elaborate on why you are against merging this PR? It's been several months. Sure, I have a long train journey today, and so I have found...