INCATools / INCATools/ontology-access-kit
unify implementation tests into a general compliance test suite
- Dominant language
- Python
- Stars
- 198
- Forks
- 35
- Avg merge
- 3d 4h
- Merged PRs (30d)
- 1
Description
Currently each *implementation* has its own test suite, and these are not connected.
Thus sql_implementation has a test db file and performs a test for neighbor/ancestor functionality; and pronto_implementation has the same for a slightly different obo file, and slightly different test cases.
We should have
- a single ontology for testing (that is converted to different forms)
- a single compliance suite, or one compliance suite per *interface*
Each implementation can be tested against the full compliance suite. There are known cases where an implementation may not implement something (e.g. some operations are impossible against remote endpoints), these would be annotated with `unittest.skip`, and we could derive a grid of which implementation can do what for the documentation
Contributor guide
Research direction
Start by mapping the separate implementation test suites, including the sql_implementation test database and the pronto_implementation OBO fixture and cases. Define how one ontology can be converted into the required forms and how compliance suites apply across interfaces. Done means implementations run against shared compliance tests, unsupported operations are explicitly skipped, and capability results can support documentation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- testing-qa
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100