Skip to content
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

Improve code coverage by adding more tests #9

Merged
merged 26 commits into from
Jun 13, 2024

Conversation

pkhalaj
Copy link
Collaborator

@pkhalaj pkhalaj commented May 31, 2024

This PR is mainly about the code coverage as mentioned in the title.

However, as a result of adding more tests, we might need to add some new testing utilities to the test_utils package and perform some minor refactoring.

Copy link

codecov bot commented May 31, 2024

Codecov Report

Attention: Patch coverage is 98.00000% with 5 lines in your changes missing coverage. Please review.

Project coverage is 96.71%. Comparing base (781891d) to head (62974a4).
Report is 42 commits behind head on master.

Files with missing lines Patch % Lines
trolldb/api/fastapi_app.py 90.90% 2 Missing ⚠️
trolldb/api/api.py 80.00% 1 Missing ⚠️
trolldb/tests/conftest.py 93.75% 1 Missing ⚠️
trolldb/tests/tests_database/test_mongodb.py 98.57% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master       #9      +/-   ##
==========================================
+ Coverage   89.96%   96.71%   +6.75%     
==========================================
  Files          24       26       +2     
  Lines         947     1067     +120     
==========================================
+ Hits          852     1032     +180     
+ Misses         95       35      -60     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@pkhalaj pkhalaj force-pushed the tests/improve-coverage branch from b3e1ec6 to 8510179 Compare May 31, 2024 16:54
pkhalaj added 6 commits June 1, 2024 20:05
This concerns two methods in the `ResponseError` class. This bug came to my attention while adding more tests!
This is needed as we are using `loguru` instead of the Python built-in logging package.
Our test is not spawning child processes.
This is to ensure that we are calling `MongoDB.close()` only if the client has been properly initialized.
This is to clarify that the return value cannot be readily used in the initialization of MongoDB.
As a result, `test_recorder.py` has been updated accordingly with the new `make_test_app_config_as_dict()`.
@pkhalaj pkhalaj force-pushed the tests/improve-coverage branch from ee52af0 to 7161505 Compare June 2, 2024 15:49
pkhalaj added 9 commits June 2, 2024 17:50
A test will be added in the next commit.
We also improve the structure of previous tests in the module. In particular, we now assert the log messages and use parametrization.
Moreover, perform some minor refactoring of the tests in the module.
TODO: These tests need to be improved so that they cover all the code paths.
@pkhalaj pkhalaj force-pushed the tests/improve-coverage branch from 01d89c4 to a6f136f Compare June 4, 2024 08:52
pkhalaj added 5 commits June 9, 2024 21:07
We have added `fastapi_app.py`. This simplifies the testing and also is aligned with separation of concerns.
This results in a correct code coverage for tests.
As a result, `api_server_process_context()` is no
longer needed and has been removed.
The former scheme is not recommended when designing REST APIs.
This led to the reintroduction of `api_server_process_context()` but it now lies in the `test_utils` module.
This concerns the case when the input to the function is a response.
@pkhalaj pkhalaj force-pushed the tests/improve-coverage branch from fa710c7 to 27733f7 Compare June 10, 2024 08:03
@@ -46,18 +46,13 @@ def id_must_be_valid(id_like_string: str) -> ObjectId:
try:
return ObjectId(id_like_string)
except InvalidId as e:
raise ValueError from e
raise ValueError(f"{id_like_string} is not a valid value for an ID.") from e
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why change the type of error?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason is that as per the requirements of Pydantic, one can either raise a ValueError or AssertionError in a custom validator. Here I have defined a custom validator for a MongoDB object ID. When it fails it raises InvalidId which is not a valid exception to signify validation failure in Pydantic, hence the need to catch the error and raise a different one.

Please let me know if my understanding of this is correct.

Reference: https://docs.pydantic.dev/latest/concepts/validators/#handling-errors-in-validators

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added a note on this to the validator's docstring.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, all good then.

trolldb/tests/conftest.py Outdated Show resolved Hide resolved
Copy link
Member

@mraspaud mraspaud left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mraspaud mraspaud merged commit eff7a1d into pytroll:master Jun 13, 2024
6 checks passed
@pkhalaj pkhalaj deleted the tests/improve-coverage branch June 13, 2024 09:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants