On 28/03/14 21:14, Claude Warren wrote:
The issue with junit4 is that the suite definition is in an annotation and
therefore has to be defined at compile time, so there is no mechanism to
define tests at runtime.
manifest based code I did attempted to provide a mechanism to create the
tests are runtime. Perhaps there is a common point here such that we can
build an annotation suite that will allow identification of a test suite
using annotations but delay the creation of the tests until runtime so that
further configuration can be applied.
Thoughts?
What I've is name the manifest file in the annotations,
@RunWith(RunnerSPARQL.class)
@Label("SPARQL [main]") // A display name.
@Manifests
({
".../sparql11-test-suite/manifest-arq-sparql11.ttl",
"../ARQ/Serialization/manifest.ttl"
})
The manifests are W3C format and can include other manifests. They also
include manifest names and test names. Not Java specific and the test
suite was used by all implementation reports. Much the same approach is
used for RDF 1.1.
The RunnerSPARQL picks up the annotations at runtime and builds the test
tree. Most of the code is SPARQL test specific.
Aside from the recursive fact that paring the manifests is done with
SPARQL to build the SPARQL test suite ... (and when it fails there is a
risk of a green line on less than all the tests!)
There is some sort of common point in the tree of tests, both you and
Jeremy have similar structures. It isn't huge though.
Andy
Claude
On Thu, Mar 27, 2014 at 4:49 PM, Jeremy J Carroll <[email protected]> wrote:
On Mar 26, 2014, at 2:21 PM, Andy Seaborne <[email protected]> wrote:
We (you, me, jeremy) seem to have ended up in a similar place.
I have used junit4 for quite a bit now, but I definitely like the ability
to define my own test suites programmatically, (which is needed for your
use case) and the Parameterized Test Runner that comes built-in is close
but not close enough; hence I roll my own
