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

[WIP] add pragma statements #5749

Merged
merged 23 commits into from
Feb 15, 2022
Merged

[WIP] add pragma statements #5749

merged 23 commits into from
Feb 15, 2022

Conversation

scharlottej13
Copy link
Contributor

@scharlottej13 scharlottej13 commented Feb 3, 2022

Pragma no cover

  • We have cases with relatively long switch-like statements ending in a final exception, e.g. ValueError "unknown value"
  • Conditional imports may need be covered with pragma statements and/or a dedicated job

WIP, because I haven't made it through all the files yet. Going in order of lowest to highest percent coverage I made it to utils.py.

cc: @ncclementi @phobson-- thanks again for your help!

@GPUtester
Copy link
Collaborator

Can one of the admins verify this patch?

@scharlottej13
Copy link
Contributor Author

scharlottej13 commented Feb 3, 2022

Files reviewed in this PR:

asyncio.py

_concurrent_futures_thread.py-- really not sure about this one! seems a lot is not covered, and I wasn't sure how easy this is to test.

proctitle.py

node.py-- wasn't sure about start_services, didn't add any pragma

objects.py-- didn't see any obvious place to add pragma here

actor.py

profile.py

metrics.py

utils_test.py-- This one was tricky and perhaps should be removed from this PR to be part of a separate discussion (per the note in the original issue)? When unsure, I added pragma no cover where the only reference was in a test that is already ignored in .coveragerc; if the function was called elsewhere in utils_test.py, I opted to not exclude it. For some functions, I had trouble finding a reference, e.g deep, slowdouble. moved to #5799

@github-actions
Copy link
Contributor

github-actions bot commented Feb 3, 2022

Unit Test Results

       17 files   -        1         17 suites   - 1   9h 47m 49s ⏱️ - 36m 22s
  2 596 tests ±       0    2 516 ✔️  -        1       79 💤 ±    0  1 +1 
21 846 runs   - 1 384  20 482 ✔️  - 1 276  1 363 💤  - 109  1 +1 

For more details on these failures, see this check.

Results for commit 51f26ad. ± Comparison against base commit 91f899e.

♻️ This comment has been updated with latest results.

@fjetter
Copy link
Member

fjetter commented Feb 3, 2022

Thank you for your effort on this! I would actually recommend opening the other files in another PR, doing this incrementally in batches. That makes reviewing a bit easier and we can merge incrementally to avoid merge conflicts

node.py-- wasn't sure about start_services

I think this is a good example for a thing we do not want to ignore. We are clearly entering this function (the if and for is hit) but for some reason the actual logic is never executed. We likely want to spend some time figuring out why this is and maybe wrote a test for it.

his one was tricky and perhaps should be removed from this PR to be part of a separate discussion

If you are not sure about this, feel free to split it off into a separate PR. In my mind the initial PRs for this should be fast and without a lot of discussion

line 110
line 368

I suggest to not ignore. I don't know how this is tested right now but both lines look like actual functionality which we should be testing imo

lines 444-503 (how hard is it to test these?)

They are hit from what I see. If you have reports were they are not hit, this is one of these "flaky" coverage places where it might pay off to have a closer look so I suggest to not ignore

Copy link
Member

@fjetter fjetter left a comment

Choose a reason for hiding this comment

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

I agree that we should split off the utils.py to another PR. I think a lot of these ignores should not be there and this may be an opportunity to clean up our API a little bit

@@ -143,7 +143,7 @@ def __getattr__(self, key):
return lambda *args, **kwargs: ActorFuture(
None, self._io_loop, result=attr(*args, **kwargs)
)
else:
else: # pragma: no cover
Copy link
Member

Choose a reason for hiding this comment

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

getattr is nasty and imo should be properly tested even for trivial cases

Suggested change
else: # pragma: no cover
else:

@@ -218,4 +218,4 @@ def go():


if __name__ == "__main__":
go()
Copy link
Member

Choose a reason for hiding this comment

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

I'm wondering if the entire CLI module should be ignored. Can we get reliable coverage information from this?

Comment on lines 17 to 18
if TYPE_CHECKING:
from ..scheduler import WorkerState
from ..scheduler import WorkerState # pragma: no cover
Copy link
Member

Choose a reason for hiding this comment

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

I assume this can be added to

distributed/.coveragerc

Lines 16 to 25 in 27e467e

exclude_lines =
# re-enable the standard pragma
pragma: nocover
pragma: no cover
# exclude nvml calls
[\s(.]nvml[\s(.]
[\s(.]pynvml[\s(.]
# exclude LOG_PDB
LOG_PDB

such that TYPE_CHECKING blocks are always ignored

@@ -271,7 +271,7 @@ async def _start(self):
self._lock = asyncio.Lock()
self.status = Status.starting

if self.scheduler_spec is None:
Copy link
Member

Choose a reason for hiding this comment

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

keep this, please. This smells like dead code or something we should be testing

@@ -348,7 +348,7 @@ def get_profile(history, recent=None, start=None, stop=None, key=None):

if stop is None:
istop = None
else:
Copy link
Member

Choose a reason for hiding this comment

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

keep this please. Either it should be tested or it shouldn't be there.

from typing_extensions import Literal

from distributed.compatibility import MACOS
from distributed.scheduler import Scheduler

try:
import ssl
except ImportError:
Copy link
Member

Choose a reason for hiding this comment

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

we could consider adding except ImportError as well to the exclude_lines

@scharlottej13
Copy link
Contributor Author

Thank you for your effort on this! I would actually recommend opening the other files in another PR, doing this incrementally in batches. That makes reviewing a bit easier and we can merge incrementally to avoid merge conflicts

Thank you @fjetter for the review! Once I address your comments I'll open up separate PRs for the other files, starting with utils_test.py.

lines 444-503 (how hard is it to test these?)

They are hit from what I see. If you have reports were they are not hit, this is one of these "flaky" coverage places where it might pay off to have a closer look so I suggest to not ignore

Oh interesting, yup in the most recent coverage report I can see they are covered. I won't ignore them, then, and will also see if I can find the report where I saw them marked as not covered.

This was referenced Feb 11, 2022
Copy link
Member

@fjetter fjetter left a comment

Choose a reason for hiding this comment

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

Thank you @scharlottej13 !

@fjetter fjetter marked this pull request as ready for review February 15, 2022 10:29
@fjetter fjetter merged commit 9f8c50b into dask:main Feb 15, 2022
@scharlottej13 scharlottej13 deleted the improve-coverage branch February 15, 2022 18:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants