49 junit integration

[pepperbob]

Hi Dimitris,

we started implementing the Runner and so far it looks quite promising. Though we need to add some features (CVs) and improve overall performance.

Maybe you can already have a glance. Feel free to comment.

Regards,
Daniel & Michael

[pepperbob]

We should undo changes in this file up to here as it's formatter related.

[jimkont]

Great work Daniel & Michael!
Some high level comments (for now).

1. I would rather use the term schema instead of ontology because it can cover other schema types that RDFUnit currently supports (or will support in the future, like shacl).

2. the file paths that are used sometimes cause initialization errors when testing from the IDE (Intellj). Maybe it is better to use the java resource naming directly

instead of Model as input we could use RDFReaders or SchemaSource/TestSource that can more transparently handle java resources.

3. I created an example test based on your code but is not picked up my maven. (although I can run it from Intellj when I set the relative paths correctly).

@RunWith(RdfUnitJunitRunner.class)
@Ontology(uri = Constants.FOAF_ONTOLOGY_URI)
public class ExampleRDFUnitRunner {

        @InputModel
        public Model getInputData() {
            return ModelFactory
                    .createDefaultModel()
                    .read("file:src/test/resources/inputmodels/foaf.rdf");
        }
}

4. re-running only failed tests (supported by the IDE) does not work but this is minor

5. we could also allow a list of @InputModel and the runner could create test combinations of schema x InputModel

6. Test descriptions could use some tweaking but I need to deal with some prefix generation related tasks first (e.g. Remove the dependency to LOV for every validation #34 / More transparent facilites to specify local alternatives for LOV schema locations for CLI #39)

overall, I am very happy to accept it as is and iterate over time but I see you made some comments already. Let me know when you are ready to merge

[pepperbob]

@jimkont Could you explain what's the thing with the Prefix URI? Just noticed we just define constant / hard coded values to satifsfy the Builder.. However not sure if this is correct.

[jimkont]

prefix are used as in turtle syntax (e.g. http://prefix.cc/popular.file.txt) and are meant to shorten the IRIs or as secondary (short) identifiers.
I also use them to override the actual schema IRI when I want to use a different ontology IRI than the default one
e.g. nif https://github.com/AKSW/RDFUnit/blob/master/data/schemaDecl.csv#L12 skips the default dereferencing and uses the latest version from github.
this way when the user checks against e.g. nif the the overridden IRI is used transparently

If we use a SchemaSource and a TestSource directly in the tests definitions, instead of Jena Models, then we can reuse the prefixes defined in the constructors and avoid the hardcoded prefixes

[jimkont]

In this case we cannot override anything by defining a prefix but the prefix can be used to improve the readability of the test description

[dhiller]

OK, so what would you propose regarding the setPrefixUri() call?

[jimkont]

To get rid off hardcoding stuff we should go with an approach similar to

@RunWith(RdfUnitJunitRunner.class)
public class ExampleTest {

    @Schema
    public SchemaSource schemaSource =
SchemaSourceFactory.createSchemaSourceSimple("foaf",
Constants.FOAF_ONTOLOGY_URI,
RDFReaderFactory.createResourceReader(Constants.FOAF_ONTOLOGY_URI));


    @TestInput
    public TestSource testSource = new TestSourceBuilder()
            .setImMemSingle()
            .setInMemReader(RDFReaderFactory.createResourceReader("inputmodels/foaf.rdf"))
            .setReferenceSchemata(schemaSource)
            .build();
}

and we can define some factory methods to simplify object construction

On Wed, Sep 23, 2015 at 12:24 PM, Daniel Hiller [email protected]
wrote:

In
rdfunit-junit/src/main/java/org/aksw/rdfunit/junit/RdfUnitJunitStatusTestExecutor.java
#51 (comment):

+import org.aksw.rdfunit.sources.TestSource;
+import org.aksw.rdfunit.sources.TestSourceBuilder;
+import org.aksw.rdfunit.tests.executors.RLOGTestExecutor;
+import org.aksw.rdfunit.tests.query_generation.QueryGenerationSelectFactory;
+import org.aksw.rdfunit.tests.results.TestCaseResult;
+
+final class RdfUnitJunitStatusTestExecutor extends RLOGTestExecutor {
+

• public RdfUnitJunitStatusTestExecutor() {

•    super(new QueryGenerationSelectFactory());
  

• }

• Collection runTest(RdfUnitJunitTestCase rdfUnitJunitTestCase)

•        throws IllegalAccessException, InvocationTargetException {
  

•    final TestSource modelSource = new TestSourceBuilder()
  

•            .setPrefixUri("custom", "rdfunit")
  

OK, so what would you propose regarding the setPrefixUri() call?

—
Reply to this email directly or view it on GitHub
https://github.com/AKSW/RDFUnit/pull/51/files#r40192614.

Kontokostas Dimitris

[dhiller]

Think we've addressed most of the issues now.

Regarding the "re-run failed tests" issue, I believe this won't be achievable, though :(

[dhiller]

@jimkont please let us know what you think :)

[dhiller]

BTW regarding the "run-test" issue you mentioned, I use intellij to run the internal test contained in RunnerTest$TestRunner, works fine for me.

[jimkont]

To get rid off hardcoding stuff we should go with an approach similar to

@RunWith(RdfUnitJunitRunner.class)
public class ExampleTest {

    @Schema
    public SchemaSource schemaSource = SchemaSourceFactory.createSchemaSourceSimple("foaf", Constants.FOAF_ONTOLOGY_URI, RDFReaderFactory.createResourceReader(Constants.FOAF_ONTOLOGY_URI));

    @TestInput
    public TestSource testSource = new TestSourceBuilder()
            .setImMemSingle()
            .setInMemReader(RDFReaderFactory.createResourceReader("inputmodels/foaf.rdf"))
            .setReferenceSchemata(schemaSource)
            .build();
}

and we can define some new factory methods to simplify object construction

[jimkont]

It is not clear what @ControlledVocabulary does

[jimkont]

If it is meant to be loaded along with the data (which is what I guess from the code) should be renamed to something like @AdditionalData but this can also be constructed directly on the @InputModel

[pepperbob]

Good Point - 'ControlledVocabulary' is just our use case (as we're loading CVs as additional data) but in general terms @AdditionalData is more suited.

In fact it gets merged with each InputModel later, but we need to keep both separated to figure out if the offending resources found during test execution is actually part of the InputModel or not.

[dhiller]

@jimkont Regarding your SchemaSource change proposal, we can't see how this would help as we need the RDFReader for test generation which is not exposed by the SchemaSource.

Aside from the initialization error handling (which could be improved) we would propose to rather merge this pull request to prepare for a release as it covers our current use cases. We would then create an issue pulling together the remaining improvements and get back when we can spend the time again.

Would that be ok for you?

[jimkont]

more than happy. do you want me to make a new release?

[dhiller]

We'd be glad if you could release this :)

[jimkont]

Thanks again for the amazing work! the release is ready
Also note that rdfunit is now in maven central http://search.maven.org/#artifactdetails|org.aksw.rdfunit|rdfunit-junit|0.7.19|