Nanopublications used as test fixtures belong in the nanopub test suite, where every implementation reads them from, rather than being copied into each consumer. #619 does that for the grlc query template it needed (added to the suite in Nanopublication/nanopub-testsuite#5, read back through org.nanopub:nanopub-testsuite-connector), which leaves the fixtures that were already here.
They are not all the same kind of thing, so this isn't one move repeated five times:
| fixture |
what it is |
already in the suite? |
used by |
np-grlc-query.trig |
published, signed, trusty (RA6T-YLqLnYd5XfnqR9PaGUjCzudvHdYjcG4GvOc7fdpA) |
yes — byte-identical to valid/signed/RA6T-….trig |
GrlcQueryTest, NanopubElementTest |
np-statusline-example.trig |
published, signed, trusty (RA58YcJyv1h-UmS8jI6UfFP6_LTAh59GTgpU_4lvBv7a4) |
no |
StatusLineTest |
np-governed-definition.trig |
synthetic, unsigned, placeholder code RAAAA… |
no |
GovernedVersionsTest, StatusLineTest |
np-nongoverned-definition.trig |
synthetic, unsigned, placeholder code RABBB… |
no |
GovernedVersionsTest |
templates/new-style-assertion-template.trig |
synthetic, unsigned, purl.org/nanopub/temp/ URI |
no |
nothing — no test references it |
Proposed work
np-grlc-query.trig — delete and read from the suite. Pure duplication: the identical file is already in valid/signed/. Two tests to repoint, no test-suite PR needed.np-statusline-example.trig — add to the suite, then read from there. A real published nanopub whose trusty URI and signature verify, so it belongs in valid/signed/ alongside the others. One test-suite PR, then repoint StatusLineTest.- The two governed/non-governed definitions — decide, don't assume. These are hand-built with placeholder artifact codes and no signature: they exist to exercise Nanodash's own governance logic, not to test whether an implementation reads nanopublications correctly. A suite whose stated purpose is validating nanopub implementations may not be the right home for them, and putting an unsigned nanopub with a fake code into
valid/ would be wrong. Worth agreeing whether they stay local, move as invalid/- or plain-category entries, or get built in code by NanopubCreator the way the newer tests do.
templates/new-style-assertion-template.trig — delete it. Nothing reads it. If it was meant as a fixture for a test that never landed, it should come back with that test, from the suite.
Note on sequencing
Anything that moves to the suite is invisible to the connector until the suite PR merges, so the consuming test has to tolerate the gap. #619 handles that with a JUnit assumption naming the pending PR, which skips until the entry lands and then runs by itself — same pattern applies here.
Nanopublications used as test fixtures belong in the nanopub test suite, where every implementation reads them from, rather than being copied into each consumer. #619 does that for the grlc query template it needed (added to the suite in Nanopublication/nanopub-testsuite#5, read back through
org.nanopub:nanopub-testsuite-connector), which leaves the fixtures that were already here.They are not all the same kind of thing, so this isn't one move repeated five times:
np-grlc-query.trigRA6T-YLqLnYd5XfnqR9PaGUjCzudvHdYjcG4GvOc7fdpA)valid/signed/RA6T-….trigGrlcQueryTest,NanopubElementTestnp-statusline-example.trigRA58YcJyv1h-UmS8jI6UfFP6_LTAh59GTgpU_4lvBv7a4)StatusLineTestnp-governed-definition.trigRAAAA…GovernedVersionsTest,StatusLineTestnp-nongoverned-definition.trigRABBB…GovernedVersionsTesttemplates/new-style-assertion-template.trigpurl.org/nanopub/temp/URIProposed work
np-grlc-query.trig— delete and read from the suite. Pure duplication: the identical file is already invalid/signed/. Two tests to repoint, no test-suite PR needed.np-statusline-example.trig— add to the suite, then read from there. A real published nanopub whose trusty URI and signature verify, so it belongs invalid/signed/alongside the others. One test-suite PR, then repointStatusLineTest.valid/would be wrong. Worth agreeing whether they stay local, move asinvalid/- orplain-category entries, or get built in code byNanopubCreatorthe way the newer tests do.templates/new-style-assertion-template.trig— delete it. Nothing reads it. If it was meant as a fixture for a test that never landed, it should come back with that test, from the suite.Note on sequencing
Anything that moves to the suite is invisible to the connector until the suite PR merges, so the consuming test has to tolerate the gap. #619 handles that with a JUnit assumption naming the pending PR, which skips until the entry lands and then runs by itself — same pattern applies here.