The other way to deal with data is to have a class of constants - no
need to parse "<a> <b> <c>", just a whole load of data for testing with.
How much do you need?
Parsing N-triples is pretty easy for a non-performant usage. Literals
are a bit fiddly but that's about it. It's little more than regexps.
If RIOT moves into core (or core without rdf and owl APIs) it will be
available but it woudl be good for the core of jena-core (i.e. Graph and
eventually DatasetGraph) to be a dependent so ROIT can be one or more
modules.
On 25/04/15 15:49, Claude Warren wrote:
what is "SSE.parse*"
SSE is a class in (currently) ARQ with many utility methods: parseNode,
parseTriple, ...
http://jena.apache.org/documentation/javadoc/arq/com/hp/hpl/jena/sparql/sse/SSE.html
lots of utilities.
https://jena.apache.org/documentation/notes/sse.html
One possibility is that testing happens in two forms - basic unit
testing along side the code and a separate "jena-system-test" package
that puts it all together.
Andy
I assume that it is not test code.
I was thinking we would create jena-core test jar that would contain all
the test code. Then test code could depend on it. If SSE.parse is in
jena-core it might make sense to use it. if it is not, then we need to ask
if we want our test code to be dependent upon code in a package outside of
the core.
Claude
On Sat, Apr 25, 2015 at 2:53 PM, Andy Seaborne <[email protected]> wrote:
On 25/04/15 13:17, Claude Warren wrote:
Bruno,
When I was working on the tests I moved many of the methods that were in
the base test classes into classes in the testing_framework package. The
packackage is visible at
http://svn.apache.org/viewvc/jena/Experimental/new-test/src/test/java/com/hp/hpl/jena/testing_framework/?pathrev=1525332
I would like to move these into the new tests that we are building as they
help with the contract tests and provide standard implementations for
various functions that make testing easier (e.g. creating a triple from
the
string "<a> <b> <c>")
SSE.parse* has that machinery (in the wrong module ATM :-()
If teh testing code all goes through one static it can use the old NT or
TTL (prefixes) reader for now depending on how clever you want that to be.
Think that the package should be in the jena-core test source tree.
Does anyone see any reason not to do this?
Would that be as a separate hierarchy for now? i.e. two test suites? It
just means that working on new tests isn't a blocker so you can finalize it
as and hen you have the time.
Also, I think that the contract tests should be created in the jena3
branch
until that is moved to to the master.
That move is going to happen very soon unless there is a reason not to.
It is ready to go. Much can still be done but it builds and is usable.
When in master, we can start SNAPSHOT builds.
If anyone wants to check it against their application code, it's good for
that.
Andy
Claude
