-
Notifications
You must be signed in to change notification settings - Fork 6
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
Add unit tests for gpm_api.io #8
Conversation
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.
The tests looks great. I have just a couple of comments ;)
…uture use, allow check_time to fix incoming str and np objects into check_date()
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.
@evanjt Check why tests do not pass CI (Python 3.8 apparently)
…s to not replace host (arthurhouftps.pps.eosdis.nasa.gov -> arthurhouftp.pps.eosdis.nasa.gov)
Codecov Report
@@ Coverage Diff @@
## main #8 +/- ##
========================================
- Coverage 0.15% 0.00% -0.16%
========================================
Files 41 40 -1
Lines 3300 3313 +13
========================================
- Hits 5 0 -5
- Misses 3295 3313 +18
|
@sphamba They are not passing as type hints became supported with standard objects rather than needing to import them from the typing library in 3.9 https://peps.python.org/pep-0585/. We can consider importing |
@ghiggi We could switch to the Python 3.8 style of type hinting (with |
I don't know |
I think changing the type hints to those compatible with 3.8 is a good balance between improving typing for future versions and supporting older Python installations, especially after seeing the amount of people using 3.8 still. If we consider adding them to the library, then the application will not run at all for <= 3.8 versions. |
At this stage, I believe most of the testing is done in this module without spending a considerable amount of time mocking requests and responses |
…lter_by_time(), modify the default None behaviour to choose utcnow() instead of now() to avoid timezone related issues
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.
I reviewed a first part
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.
I finished to review the rest of the code. @evanjt we can have a Zoom in the coming days to clarify what remains to be done ;)
Have a nice week !
) -> None: | ||
"""Test check_download_status function""" | ||
|
||
for product in products: |
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.
Here we don't need to loop over products. product is an argument of _check_download_status
just to display an informative message, but does not condition execution. So define a dummy product string within the test.
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.
If the function changes in the future to be restricted to a product for whichever reason, should we not keep the loop in to check all possible products work with it as defined in the internal product list?
If it's a case of simplifying the test routine, I'm happy to simplify it, specifying a random string here would restrict the tests to a static constant outside of the scope of the realistic product list, perhaps we could just use the first element of the list?
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.
Ok I agree. In the end I guess does not take lot of time to execute this test.
…the mock_configuration fixture
Dear @ghiggi , This pull request has been open for more than one month. Can we close it without further changes and create new issues to address any important remarks you may have for the rest of the project? Keeping a pull request open for such a long time is not ideal in terms of traceability. Furthermore, the time spent on this task is at the expense of others. Could we be picky at the end of the project ? |
Hey @regislon and @evanjt ! |
… as to not flatten an already flattened list
Hi @ghiggi thanks for the comments. I replied to some of your messages and made changes last week but not all of them as my time was limited. Furthermore, as I understood from our last meeting, you did not want more hours spent on this module, so with the time I had, I limited it to the ones that did not require additional modifications of the code base. With respect to your latest comments, the issue with the microseconds to seconds was a misjudgement of mine through the threads in this PR earlier in July, and have corrected it, along with the other items you have noted. |
Prework
What kind of change does this PR introduce? (check at least one)
Does this PR introduce a breaking change? (check one)
If yes, please describe the impact and communicate accordingly:
The PR fulfills these requirements:
bugfix-<some_key>-<word>
doc-<some_key>-<word>
tutorial-<some_key>-<word>
feature-<some_key>-<word>
refactor-<some_key>-<word>
optimize-<some_key>-<word>
fix #xxx[,#xxx]
, where "xxx" is the issue number)If adding a new feature, the PR's description includes:
Other information:
Related GitHub issues and pull requests
Summary
Please explain the purpose and scope of your contribution.
Incorporate tests for gpm_api.io