Replies: 1 comment
-
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
TL;DR: I'm proposing two things:
Separating unit and integ tests
Right now, integration tests live in the same folder as unit tests, here: https://github.com/rucio/rucio/tree/master/tests There is no way to tell them apart from the file structure; the only way to identify them is by looking at this file https://github.com/rucio/rucio/blob/cf767d0e033c56c6e2eec9705c871023288380e7/.github/workflows/integration_tests.yml to see which tests are selected to be run.
I think it would benefit us to have separate folders for integ and unit tests:
integration_tests.yml
script - instead of having to remember to maintain the correct list of integration tests in there, we can simply tell it to run the tests in the "integ_tests" folderUsing more mocks in the unit tests
This point would benefit from the previous point - if there is a clear separation between unit tests and integration tests, then it's easier to see which tests could be simplified to only test the unit in question.
As an example, this test is meant to check that the metrics API endpoint functions properly: https://github.com/rucio/rucio/blob/master/tests/test_request.py#L296
At this API endpoint, this function is executed: https://github.com/rucio/rucio/blob/master/lib/rucio/api/request.py#L223, querying the database twice via
get_rse_id
. This function is then called: https://github.com/rucio/rucio/blob/master/lib/rucio/core/request.py#L1848, which also queries the database viaget_request_stats
.Instead of actually querying the database, the response form the DB query could be mocked, allowing us to only test the element that we care about: the metrics API request. This would probably also result in a faster test, as mocking a DB response instead of actually querying the DB should be faster.
Beta Was this translation helpful? Give feedback.
All reactions