Testing Proposal

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

I would like to see Jena adopt a set of contract tests.  I recently wrote
an article for Dr. Dobb's [1] concerning contract testing.  In it I use the
experimental/new_tests as an example.

The basic concept is we provide a set of contract tests for expected
extension points like the Graph SPI.  Implementers of Graph would be able
to run the contract test to ensure that their implementations match what is
expected.  To be honest, I have implemented what I thought was a proper
Graph implementation only to find that it was missing some component.

My proposal is that as we go through the process of refactoring and
building version 3 we create contract tests for the extension points.  In
so doing we can more completely document what the requirement is and
provide a test for it.

For example the a Graph contract test case may be:

/* Inserting into the graph requires that the graph listener be notified of
the insertion. */
@ContractTest
public void notifyInsertion()
{ ..... }

Any thoughts or objections?

Claude


[1] http://www.drdobbs.com/testing/simplifying-contract-testing/240167128

-- 
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren

GraphAdd

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

On 11/06/14 13:56, Claude Warren wrote:
>> A comment about the Graph interface:
>> >
>> >I see no point in GraphAdd and would prefer one interface.
>> >
>> >The important difference is mutable/immutable but it is rarely fixed for
>> >the entire lifetime of a graph in Jena and the collections style immutable
>> >converters is better (equivalently, read-only views of a graph or dataset).
>> >
>> >Only if interfaces actually took "ImmutableGraph" because they needed them
>> >would it make sense to me but that is a huge change in both code and
>> >overall architecture.
>> >
>> >         Andy
>> >
>> ><claude>
> I agree with you.
>
> Note:  It should be fairly easy to write an ImmutableGraph wrapper that
> throws an exception when any method that updates the graph is called.
>   Actually, the security classes already do this for cases where the user
> does not have access.
>
> Are there really that many places where GraphAdd is explicitly used?
>
> </claude>


According to Eclipse, the only use of the work GraphAdd are as a 
superinterface to the Graph interface, the interface defn of GraphAdd 
itself and a class GraphAddList.

There no calls to the constructor of GraphAddList.

Might as well deprecate GraphAddList as a sign.

	Andy

Re: Testing Proposal

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

Comments inline


On Wed, Jun 11, 2014 at 12:27 PM, Andy Seaborne <an...@apache.org> wrote:

> On 10/06/14 11:25, Claude Warren wrote:
>
>> I would like to see Jena adopt a set of contract tests.  I recently wrote
>> an article for Dr. Dobb's [1] concerning contract testing.  In it I use
>> the
>> experimental/new_tests as an example.
>>
>> The basic concept is we provide a set of contract tests for expected
>> extension points like the Graph SPI.  Implementers of Graph would be able
>> to run the contract test to ensure that their implementations match what
>> is
>> expected.  To be honest, I have implemented what I thought was a proper
>> Graph implementation only to find that it was missing some component.
>>
>> My proposal is that as we go through the process of refactoring and
>> building version 3 we create contract tests for the extension points.  In
>> so doing we can more completely document what the requirement is and
>> provide a test for it.
>>
>
> Is this changes to the tests or changes to tests and things like Graph
> under main/java?
>
> I do think we need not to overload Jena3 with too many item that must be
> done before first release.
>
> <claude>
I would like to see this as ancillary to what we have currently.  I think
there is a lot of test code that needs to be cleaned up or consolidated.
 But this is not that process.

I see this proceeding as:
 1. begin to add the contract tests and release what is available when the
standard releases are done.
 2. As coverage moves to contract tests remove duplicate coverage from
non-contract tests.
 3. For tests that don't make sense as contract tests, keep them and bring
them up to Junit 4.  Along the way we would develop and release a Juni4
test suit class that allows you to specify the tests after it is
constructed (i.e. not in an annotation) ala Junit3 TestSuite. -- this is
the issue you and I and several others have already solved so just bring it
into a formal class for Jena testing.
</claude>

>
>
>> For example the a Graph contract test case may be:
>>
>> /* Inserting into the graph requires that the graph listener be notified
>> of
>> the insertion. */
>> @ContractTest
>> public void notifyInsertion()
>> { ..... }
>>
>> Any thoughts or objections?
>>
>
> If it's better test structures then +1.
>
> Is there anything stopping you in continuing with
> https://svn.apache.org/repos/asf/jena/Experimental/new-test/
> ?
>

<claude>
No, there is nothing blocking.  I just wanted to get wider view and
agreement before I spent a lot more time on it.
</claude>

>
> As it may take time, we can simply have two sets of tests for a while.
> (Actually, as you have found out, we have "old" and "older" groups of tests
> in core already).
>
> <claude>
my thoughts exactly -- can we come up with a process to clean up the tests?
</claude>

>
>> Claude
>>
>>
>> [1] http://www.drdobbs.com/testing/simplifying-contract-testing/240167128
>>
>>
> A comment about the Graph interface:
>
> I see no point in GraphAdd and would prefer one interface.
>
> The important difference is mutable/immutable but it is rarely fixed for
> the entire lifetime of a graph in Jena and the collections style immutable
> converters is better (equivalently, read-only views of a graph or dataset).
>
> Only if interfaces actually took "ImmutableGraph" because they needed them
> would it make sense to me but that is a huge change in both code and
> overall architecture.
>
>         Andy
>
> <claude>
I agree with you.

Note:  It should be fairly easy to write an ImmutableGraph wrapper that
throws an exception when any method that updates the graph is called.
 Actually, the security classes already do this for cases where the user
does not have access.

Are there really that many places where GraphAdd is explicitly used?

</claude>

-- 
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren

Re: Testing Proposal

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

On 10/06/14 11:25, Claude Warren wrote:
> I would like to see Jena adopt a set of contract tests.  I recently wrote
> an article for Dr. Dobb's [1] concerning contract testing.  In it I use the
> experimental/new_tests as an example.
>
> The basic concept is we provide a set of contract tests for expected
> extension points like the Graph SPI.  Implementers of Graph would be able
> to run the contract test to ensure that their implementations match what is
> expected.  To be honest, I have implemented what I thought was a proper
> Graph implementation only to find that it was missing some component.
>
> My proposal is that as we go through the process of refactoring and
> building version 3 we create contract tests for the extension points.  In
> so doing we can more completely document what the requirement is and
> provide a test for it.

Is this changes to the tests or changes to tests and things like Graph 
under main/java?

I do think we need not to overload Jena3 with too many item that must be 
done before first release.

>
> For example the a Graph contract test case may be:
>
> /* Inserting into the graph requires that the graph listener be notified of
> the insertion. */
> @ContractTest
> public void notifyInsertion()
> { ..... }
>
> Any thoughts or objections?

If it's better test structures then +1.

Is there anything stopping you in continuing with
https://svn.apache.org/repos/asf/jena/Experimental/new-test/
?

As it may take time, we can simply have two sets of tests for a while. 
(Actually, as you have found out, we have "old" and "older" groups of 
tests in core already).

>
> Claude
>
>
> [1] http://www.drdobbs.com/testing/simplifying-contract-testing/240167128
>

A comment about the Graph interface:

I see no point in GraphAdd and would prefer one interface.

The important difference is mutable/immutable but it is rarely fixed for 
the entire lifetime of a graph in Jena and the collections style 
immutable converters is better (equivalently, read-only views of a graph 
or dataset).

Only if interfaces actually took "ImmutableGraph" because they needed 
them would it make sense to me but that is a huge change in both code 
and overall architecture.

	Andy