Andy,
The contract is "equivalent to", so I don't expect it to be exactly like a
parser and not exactly like a string either. I'll have to think about this
again. I reviewed it in my mind recently when I was looking at the update
builder stuff.
The problem with doing parse( builder.toString() ) and comparing the result
is that the toString() performs the build() and then toString() on the
result. So the test becomes effectively query = parse( query.toString() )
For the union question: I used the union-of-one construct because it was
available. The test can easily add a second side to the union.
is the union-of-one still legal during the construction of the query? The
expected usage in the builder is:
{noformat}
builder.addUnion( <select-type-statement> ).addUnion(
<select-type-statement>)
{noformat}
Currently the code builds a union-of-one and adds the next union to it. Do
I need to think about how to change this?
I could add a check to ensure that a union-of-one is not generated in the
final result.
Contract Testing Q:
The contract testing looks for testing classes on the class path during
testing. Depending on how you build your projects the test jars may not
have been updated / installed on your system. In this case a complete
rebuild will be necessary.
The contract test runner scans the classpath looking for classes annotated
with @Contract( some-interface-class ) and determines if the class under
test implements it and if so adds it to the suite.
Are you saying that changes to classes were not detected or changes to
test-classes were not detected?
Claude
On Tue, Jun 20, 2017 at 10:04 PM, Andy Seaborne <[email protected]> wrote:
> Claude,
>
> A couple of issues in jena-querybuilder from JENA-369. These are in
> commits I made today (2017-06-20).
>
> 1/ I had to change some "testList" to recognize the new pretty list
> output. But only some. See WhereHandlerList testList/testListInTriple.
>
> There "testList" does not trigger pretty printing so it must be a
> different syntax structure. It may not trigger efficient query.
>
> What may help testing is that Query.equals is a deep structural
> comparison.
>
> If the contract is "like the parser", then writing the expected answer as
> a string, parsing it then using Query.equals will be more robust.
>
> If the contract is for building strings, then running builder.toString,
> parse that string then compare is moer robust than regexs.
>
>
> 2/ testSetVarsInUnion
>
> This creates a UNION of one element which is illegal SPARQL.
>
> I've put back the output old format (ElementFormatter) for this for now
> but it is not syntactically correct. It would be better if generated a
> legal query - I had changed it to create "{ pattern }" hence { { pattern }
> }" where as the test is for the original and bad syntax "{ UNION { pattern
> } }".
>
> Is this a deeper issue about allowing UNION-of-one in the first place?
>
> Andy
>
> PS I also had to do a complete rebuild for the contract tests to pick up
> changes across modules in Jena. Do you know why this might be?
>
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
