Open cthoyt opened 1 year ago
@cthoyt imo the tests done on the public endpoints should be run in a completely different workflow than all other tests that are running fully locally
I am not really familiar with tox
, but ideally you should have 2 main commands to run the tests, which you can just put in separate folders (or any other mechanism depending on what's best with tox)
e.g. tox tests/integration
for fully local tests on the current state of the source code, and tox tests/production
for tests on the production API
And have 2 different GitHub actions workflow to run the test (so you see quickly if the integration tests are failing, or if the production tests are failing, without confusion). And this way you can easily define a different trigger for the production tests (e.g. CRON to run every week)
If you want to only implement production test for the curies
service then it could makes sense to put them in this repository. But I would see it better fitting in the bioregistry
repo, it makes more sense since you are testing the production deployment of the bioregistry
in the end. And that will enable you to easily add production tests for other features than the mapping service, without having 2 different workflow to track for the bioregistry production deployment
I've excerpted this from #49 - this code tests public SPARQL interfaces are able to use the Bioregistry. I'm not sure if this belongs in this package, though