I have added a contract testing branch and have added the contract tests
for all graphs in the core code. I also have contract tests for several
other interfaces defined but no suites to exercise them. I recall a recent
conversation where tile names were given TS_ prefix for "test suite&qu
There is a set of contract tests (and test helpers) on the
"add-contract-tests" branch. That branch works and has minimal change from
the current tests. Those changes are adding the junit-contract runner and
plugins.
It makes no change to the execution.
The problem that I am having
I have merged the contract tests into the main code branch.
There is an overview of contract tests on the wiki at
https://cwiki.apache.org/confluence/display/JENA/Contract+Tests
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linked
I am looking for a set of tests that I would call contract tests.
I am not looking for unit tests that show a model insert works but
rather things like the following:
// create a model
Model m = ModelFactory.createDefaultModel();
// create a resource
Resource r = m.createResource( &quo
together
and easy to find in a directory listing.
Assuming that we use TS_ and TC_ as prefix, I'd prefer a CT_ prefix rather than
_CT, just to follow a convention.
Bruno
From: Claude Warren
To: dev@jena.apache.org; Bruno P. Kinoshita
Sent: Monday, April 27, 2015 6:33 PM
Subje
g that we use TS_ and TC_ as prefix, I'd prefer a CT_ prefix rather
> than _CT, just to follow a convention.
> Bruno
>
> From: Claude Warren
> To: dev@jena.apache.org; Bruno P. Kinoshita
> Sent: Monday, April 27, 2015 6:33 PM
> Subject: contract tests.
>
> I have
a convention.
Bruno
From: Claude Warren
To: dev@jena.apache.org; Bruno P. Kinoshita
Sent: Monday, April 27, 2015 6:33 PM
Subject: contract tests.
I have added a contract testing branch and have added the contract tests
for all graphs in the core code. I also have contract tes
_ as prefix, I'd prefer a CT_ prefix
>>> rather
>>> than _CT, just to follow a convention.
>>> Bruno
>>>
>>>From: Claude Warren
>>> To: dev@jena.apache.org; Bruno P. Kinoshita
>>> Sent: Monday, April 27, 2
On 19/05/15 20:25, Claude Warren wrote:
There is a set of contract tests (and test helpers) on the
"add-contract-tests" branch. That branch works and has minimal change from
the current tests. Those changes are adding the junit-contract runner and
plugins.
It makes no change to the
parallel for now, but I expect we would move a fair number of tests to it
as a replacement.
On Wed, May 20, 2015 at 10:25 AM, Andy Seaborne wrote:
> On 19/05/15 20:25, Claude Warren wrote:
>
>> There is a set of contract tests (and test helpers) on the
>> "add-contra
org.xenei:junit-contracts. With all due respect, having longterm
(years!) jena testing depend on that is not ideal.
Andy
On Wed, May 20, 2015 at 10:25 AM, Andy Seaborne wrote:
On 19/05/15 20:25, Claude Warren wrote:
There is a set of contract tests (and test helpers) on the
"add-co
On 19/05/15 20:25, Claude Warren wrote:
There is a set of contract tests (and test helpers) on the
"add-contract-tests" branch. That branch works and has minimal change from
the current tests. Those changes are adding the junit-contract runner and
plugins.
It makes no change to the
I'll have to go back and review the dependency tree.
The contract tests should only introduce:
1) a junit runner and associated annotations.
2) a maven mojo to report on the testing structure.
I think the client requirement comes in becaue there is a command line
version of the mojo. I&#
On 11/06/15 14:35, Claude Warren wrote:
I'll have to go back and review the dependency tree.
The contract tests should only introduce:
1) a junit runner and associated annotations.
2) a maven mojo to report on the testing structure.
I think the client requirement comes in becaue there
Claude,
I trying to understand the contract testing. I have been looking at
GraphMem_CS and DeltaTest mainly. Are they good examples?
What's the way to find out what classes are discovered and tested?
contract-test-maven-plugin -- what's the role of this plugin? because
the surefire setup
ote:
>
>> I'll have to go back and review the dependency tree.
>>
>> The contract tests should only introduce:
>> 1) a junit runner and associated annotations.
>> 2) a maven mojo to report on the testing structure.
>>
>> I think the client requirement
ility to filter out specific classes, keep
that in mind while reading the descriptions below.
interfaces.txt
contains a list of all the discovered interfaces and the contract tests for
them as well as a list of all classes with flags to indicate if they are
annotated with @Contract, @ContractImp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 25/11/12 14:15, Claude Warren wrote:
> I am looking for a set of tests that I would call contract tests.
I hope you're not trying to implement model. Will assume Graph.
> Basically a set of tests that prove an implementation meet
25/11/12 14:15, Claude Warren wrote:
>> I am looking for a set of tests that I would call contract tests.
>
>
>
> I hope you're not trying to implement model. Will assume Graph.
>
>> Basically a set of tests that prove an implementation meets all
>> the cont
Claude,
This is "for information" - I think I've solved the problem.
A couple of days ago I corrected the surefire test setup to explicitly
name TestPackage (was com.hp.hpl. ...).
org/apache/jena/test/TestPackage.java
**/*_CS.java
and now we have:
https://builds.apache.org/job/J
The javadoc for the modelCon methods getBag(), getSeq() and getAlt()
indicate that the returned resource should exist before the method is
called.
If the resource does not exist, the default implementation seems to create
one. However the resulting resources are different from the createBag,
crea
It is possible (and probable) that the contract code scanner is loading
them. At one point I thought I was loading classes but not initializing
them. I will look into this.
Claude
On Mon, Jul 13, 2015 at 1:27 PM, Andy Seaborne wrote:
> Claude,
>
> This is "for information" - I think I've sol
On 13/07/15 13:53, Claude Warren wrote:
It is possible (and probable) that the contract code scanner is loading
them. At one point I thought I was loading classes but not initializing
them. I will look into this.
Not urgent as my fix seems to have fixed it [famous last words]. (and
now mav
Claude Warren created JENA-1457:
---
Summary: Graph contract tests do not properly support transactions
Key: JENA-1457
URL: https://issues.apache.org/jira/browse/JENA-1457
Project: Apache Jena
mean "must use transactions".
The details depend on the implementation.
> Graph contract tests do not properly support transactions
> -
>
> Key: JENA-1457
> URL: https://
the graph supports transactions and
uses them otherwise no transaction code is called.
> Graph contract tests do not properly support transactions
> -
>
> Key: JENA-1457
> URL: https://iss
non-transactional behaviour. The contract
tests have no way to be configured.
At the moment, TDB2 requires explicit transactions and it's the only one of the
project's storage components that does. TIM and TDB1 do not require
transactions, though once a TDB1 dataset has been used trans
sent immutable graphs out to sea. Maybe we can think about
representing transactionality differently in a new API?
> Graph contract tests do not properly support transactions
> -
>
> Key: JENA-1457
&g
[
https://issues.apache.org/jira/browse/JENA-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren reassigned JENA-1457:
---
Assignee: Claude Warren
> Graph contract tests do not properly support transacti
hor: Claude Warren
Date: 2018-01-21T13:12:19Z
fixes JENA-1457
Removed incorrect JSONInput.java
> Graph contract tests do not properly support transactions
> -
>
> Key: JENA-1457
>
ssue:
https://github.com/apache/jena/pull/343
Yes - there are problems with JSONInput. This is visible in the {{.patch}}
form. It looks like changes were copied from Jena master and separately
committed.
> Graph contract tests do not properly support trans
)) );
```
makes the tests shorter and clearer.
> Graph contract tests do not properly support transactions
> -
>
> Key: JENA-1457
> URL: https://issues.apache.org/jira/browse/JE
uest at:
https://github.com/apache/jena/pull/343
> Graph contract tests do not properly support transactions
> -
>
> Key: JENA-1457
> URL: https://issues.apache.org/jira/browse/JENA-1457
&g
04T11:05:28Z
Merge branch 'master' into FixGraphContractTestTransactionUsage
commit 0d0beae44bf92ddb7b4b755d58819621d7163d75
Author: Claude Warren
Date: 2018-02-04T11:11:46Z
reverted to master version
> Graph contract tests do not properly support transactions
> ---
t at:
https://github.com/apache/jena/pull/352
> Graph contract tests do not properly support transactions
> -
>
> Key: JENA-1457
> URL: https://issues.apache.org/jira/browse/JENA-1457
&g
mmit 8567e272d8d1bb33284ee2c4bdba056b69d76139 in jena's branch
refs/heads/master from [~cla...@xenei.org]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=8567e27 ]
JENA-1457 Fix graph contract test transaction usage
this closes #352
> Graph contract tests do not properly support
[
https://issues.apache.org/jira/browse/JENA-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Warren resolved JENA-1457.
-
Resolution: Fixed
Fix Version/s: Jena 3.7.0
> Graph contract tests do not properly supp
gt; tabpanel&focusedCommentId=16306579#comment-16306579 ]
>
> Andy Seaborne commented on JENA-1457:
> -
>
> "supportsTransactions" does not mean "must use transactions".
>
> The details depend on the implementation.
>
&
38 matches
Mail list logo
