querybuilder - txt based tests

[Andy Seaborne <an...@apache.org>]

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?

Re: querybuilder - txt based tests

[Andy Seaborne <an...@apache.org>]

On 20/06/17 23:04, Claude Warren wrote:
> 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() )

String contract:

Query expected = QueryFactor.create("...");

// This will loose the internal structure due to builder
// and test the structures geneated by the parser does.
Query built = parse( builder.buildString() )

assertEquals(expected,built)


Query contract: // structure test.

Query expected = QueryFactor.create("...");
Query built = builder.build() )
assertEquals(expected,built)


> 
> 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? 

Its illegal in a query - UNION is

{..} UNION {..} UNION {..}

> 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.

At a minimum it an error to generate a union of one.

So either, throw an expection or generate "{ pattern }" (including 
inside {}) which is the moral equivalent.

IMO The second is nicer.  Tat is what I changed the formatter to do so 
at least it generated something even if it is changing the query a bit 
(round trip checking will fail but then it fails currently as it can't 
be parsed at all)

> 
> 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?

The former - classes were not detected including inside a maven build 
that is doing an "install".  It seems to pick up the previous install, 
the external classpath not the one during the "install" cycle when there 
is a new one somewhere.

     Andy

> 
> Claude
> 
> On Tue, Jun 20, 2017 at 10:04 PM, Andy Seaborne <an...@apache.org> 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?
>>
> 
> 
> 

Re: querybuilder - txt based tests

[Claude Warren <cl...@xenei.com>]

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 <an...@apache.org> 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