Releases: TranslatorSRI/SRI_testing
Releases · TranslatorSRI/SRI_testing
"HopLite" version of SRI Testing
- Pruning the release 2# down to size as the SRI Testing 'light' version, branch code-named 'Hoplite' (an ancient Greek civilian soldier). 'Hoplite' is essentially lacking the TRAPI schema and Biolink Model validation of TRAPI Responses and simply verifies that test input edges are recovered in the TRAPI Response results. Setting the environment variable 'FULL_VALIDATION' to any non-empty value (default: None) triggers the original 'full' validation. The Test Run Summary JSON report has a 'mode' tag set accordingly either to value "FullComplianceValidation" or "HopLite".
Full SRI_Testing 'classic' release with full reasoner-validator 3.9.4
- Upgrade to reasoner-validator 3.9.4: fixed methods moved into validation classes
- Upgrade to reasoner-validator 3.7.1: added 'sources' of validation messages to reports
- Upgrade to reasoner-validator 3.6.2 with additional repair of SRI Testing test edge validation in Response
- Upgrade to reasoner-validator 3.6.1 with 'critical' validation errors
- extracted OneHop test code relating to inverse predicate into get_inverse_predicate() method in BiolinkValidator class
- various TRAPI edge case validation against Knowledge Graph, moved from SRI Testing harness to TRAPIValidator class
- Upgraded to reasoner-validator 3.5.8 containing the above code
- refactored SRI Testing code to suit
- TRAPI call method moved to the reasoner-validator.trapi package module in release 3.5.6
Another iteration to fix the chokidar dependency glitch
Moved chokidar to be a dev dependency
Patch attempting to fix missing dashboard package dependencies
Dashboard UI updated to latest back end validation code
- Vue.js dashboard codebase using Node 20 / npm
- Poetry dependencies updated with missing UI dependencies; Dockerfile code repaired
- Back end validation using reasoner-validator 3.5.4
Update reasoner-validator / clarify CLI docs
- upgrade to reasoner-validator 3.2.4
- clarified CLI docs, especially, use of ara_id SKIP and testing of subsets of (possibly wildcard) kp_id or ara_id identified services
Cleaned up /registry endpoint
/registry data initialized globally as a singleton at application startup
x-maturity and complex info.x-trapi.test_data_location aware
- back end engine and web service API (but not yet UI) is fully x-maturity aware
- /registry reports (lists of) x-maturity associated with KP and ARA resources
- /run_tests accepts an optional
x-maturity
constraint (otherwise defaults to one sensiblex-maturity
per test run) - diverse reports now report x-maturity
- back end engine gracefully deals with diverse complex info.x-trapi.test_data_location specs
x-maturity
constraints drive test data selection- lists of test data files (from lists of test data urls) are merged into single test edge data runs
Enhanced documentation APIs for access by the dashboard
Added documentation web service API's /code_entry
and /unit_tests
for front end documentation help functions