-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Validator overhaul #417
Validator overhaul #417
Conversation
Yay! This PR is all I've ever dreamed of... 🤩 |
Codecov Report
@@ Coverage Diff @@
## master #417 +/- ##
==========================================
- Coverage 91.66% 91.48% -0.19%
==========================================
Files 60 61 +1
Lines 2856 3065 +209
==========================================
+ Hits 2618 2804 +186
- Misses 238 261 +23
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
Give it a while... having to unpick my code from a couple of weeks ago from the other PRs we've merged recently. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some very few comments.
There are a lot of new stuff (it seems to me) in the validator, which is absolutely awesome!
But maybe we can have a live walkthrough at some point, perhaps via Zoom or some such?
Yeah, I'm happy to. I think at the very least I need to write a fat module docstring and some notes on how to extend it... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking very clean now, great work @ml-evs !
From the new fancy in-line codecov warnings, it seems there are a lot of code-blocks that are not being checked in the test_case
function, i.e., we should probably have a static test file that represents a response with some errors?
Also, there are a lot of stuff in the validator file. I have tried to pick out some nit-picky stuff (like the doc-strings, type-info, etc.), which should be applied in a more broader sense throughout the file.
Furthermore, I am unsure whether I have actually found all I wanted.
I think it's a good idea to check which lines are not covered in the coverage tests and attempt to add some mock-responses, e.g., static files that should test these various lines?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added some doc strings for the tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lot's of nitpicking here - mainly doc strings and such.
After this has been addressed, I'd say this should be merged.
Again, great job here @ml-evs !
I think that's all your docstring changes now @CasperWA, plus the SystemExit stuff in 60772e5 that I mentioned, and the changes to make most of the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Last change I just spotted.
After that I'll approve and you can merge.
If you wish to convert this PR to several commits, instead of a single, I think that's fair enough. E.g., one for the move separately and then the updates?
- Split validator into validator and utils submodules - Add validator specific-coverage report - Disable parsing filter examples from specification for validation - Removed `optimade.validator.data` submodule - Removed corresponding invoke task - Removed tests from validator - Minor tweaks, function renames and update docs - Added dynamic filters of every field based on type reported in entry info - Add another test client that fakes HTTP exceptions - Created optimade.validator.config module - Updates to @test_case decorator, and test for MUST fields in entry info - Added test to check that all MUST properties are present in entry info - Allow test cases to return None to indicate that the test should be ignored. The use case here is e.g. if an optional field is missing, then we don't care and the test can be ignored - Added `multistage` option to `@test_case` that suppresses output and counters of success on multistage tests - Added hard filter to running optional tests in @test_case itself - Made deserialization of multi-entry endpoints optional
- Improved module docstrings - Fixed hardcoded endpoint in logging - Updated base info error message - Removed extraneous base info attribute - Tweaked endpoint variables and added missing logging - Make wider use of config values in error messages - Tidied some function docstrings - Remove argument from test_versions - Added middle ground verbosity - Better handling of fatal errors (SystemExit) in the test_case decorator - Standardization of test_case API - Unify test_case decorator and wrapped method API by returning string summary in both cases - Updated all type hints and docstrings - Slightly refactored test_case decorator for clearer exception handling - Add validator.utils tests for @test_case decorator - Remove "Keyword arguments" from docstrings - Made many validator methods/attributes private
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job with this @ml-evs !
Always improved by your reviews 👍 |
This PR updates the way we do validation. Instead of applying an arbitrary list of filter examples from the spec (which provide useless results), this PR adds the following:
/info
endpoint{"int_field": 1, "string_field": "foo"}
), then:int_field = 1
,int_field >= 1
and so on, making sure that the results are all consistent (i.e.int_field = 1
returns at most as many results asint_field >= 1
).This PR also introduces some extra changes:
@test_case
decoratordata_returned
#402 by testing thatdata_returned
matchesdata_available
when there's no filterThere are still many things missing from this PR, but I think its at a useful stage (and will require some effort to review...):
Still missing:
AND
andOR
NOT
HAS ONLY
KNOWN
andUNKNOWN