Juri Leino

@adamretter I cannot follow. Both expected and actual _are_ necessary in every case.

Your proposal, @adamretter, will not work. Here are the main issues: - both the actual and expected values can be sequences and will be mashed together into a single sequence...

@adamretter I am sure you noticed that test:fail#0, and test:fail#1 were added to this PR along with their tests. So, if an assertion does not need to expected and actual...

While one _can_ leave the values empty, it will result in following output in jUnit 

I believe two key purposes of a testing framework got confused here: - assertions - reporting While the former has to have the expected and actual value the latter needs...

The only point I can think of is that it would be one parameter less, three instead of four. Developer experience and help from tooling outweighs this argument by a...

@adamretter can you elaborate on why you are against merging this PR? It's been several months.

Interesting comments. I would like to point out that the introduction of types and the additional test:fail signatures where requested by you @adamretter . Now to my surprise you are...

see https://github.com/eXist-db/exist/pull/4332#issuecomment-1098942507 > I think the full function signature for a `test:fail` function should look like: > > ```xq > test:fail($code as xs:QName?, $description as xs:string, $failure-object as item()*) as...

Also important to point out: `test:fail` does _raise an error_ of a specific type. Wich in turn means it _is_ fully compatible with the current design of XQSuite, with the...