Skip to content

bpo-29984: Improve 'heapq' test coverage #992

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

Merged
merged 3 commits into from
Jun 1, 2019

Conversation

rkday
Copy link
Contributor

@rkday rkday commented Apr 4, 2017

This brings coverage of the heapq module to 100%.

The doctest change is a bit weird, so I've made that a separate commit so it can be straightforwardly backed out if it's too weird. I dug into why tests.addTests(doctest.DocTestSuite(py_heapq)) doesn't find any tests and it's because the comparison here doesn't return True, which I suspect is because the module is loaded with import_fresh_module.

(This is a pretty trivial change - I'm just improving test coverage somewhere to get started with contributing to Python, per https://docs.python.org/devguide/coverage.html)

https://bugs.python.org/issue29984

@mention-bot
Copy link

@rkday, thanks for your PR! By analyzing the history of the files in this pull request, we identified @rhettinger, @tiran and @ezio-melotti to be potential reviewers.

@@ -135,6 +153,13 @@ def test_heappushpop(self):
x = self.module.heappushpop(h, 11)
self.assertEqual((h, x), ([11], 10))

def test_heappop_max(self):
Copy link
Contributor

Choose a reason for hiding this comment

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

What is the line being tested? heappop_max() just calls heappop_internal() which is also used by the regular heappop(). I prefer testing the latter because it is part of the public API. Likewise, the test should apply to both the C code and the pure python code (eventhough only the latter has a special case, the test should pass for both). Alternatively, if you specifically want to exercise heappop_max(), it would be best to do it through the public function that uses it, merge().

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's

return lastelt
(the return statement used when the heap is now empty and doesn't need rebalancing).

I did wonder if I could test this via merge, but it looks like merge has an optimisation where it never calls heappop_max on a one-item list (

while len(h) > 1:
).

I'll change this test to be called on self.module, but I can't see a way to hit that line of Python code by just going through the public API (though I could refactor it to only have a single return statement?).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually, this already uses self.module, so I think this is does apply to/pass for both the C and Python code.

Lib/heapq.py Outdated
@@ -599,9 +599,3 @@ def nlargest(n, iterable, key=None):
from _heapq import _heappop_max
except ImportError:
pass


if __name__ == "__main__":
Copy link
Contributor

Choose a reason for hiding this comment

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

Please leave this in. I use it when doing maintenance for the module (we have many such cases in the standard library.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep, will do.

  • Is the rest of the change (to run the doctests as part of the test suite) useful or should I just revert the commit?
  • Is there anything I should do to mark these lines as uncovered so that coveragepy reports 100%? (I looked, but the other modules with this snippet like difflib and pickle also don't have 100% coverage yet.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I saw that pragma: nocover gets used elsewhere (e.g.

except Exception: # pragma: nocover
) so I've done that.

@brettcannon
Copy link
Member

To try and help move older pull requests forward, we are going through and backfilling 'awaiting' labels on pull requests that are lacking the label. Based on the current reviews, the best we can tell in an automated fashion is that a core developer requested changes to be made to this pull request.

If/when the requested changes have been made, please leave a comment that says, I have made the requested changes; please review again. That will trigger a bot to flag this pull request as ready for a follow-up review.

@rkday
Copy link
Contributor Author

rkday commented Mar 3, 2018

I have made the requested changes; please review again

@bedevere-bot
Copy link

Thanks for making the requested changes!

@rhettinger: please review the changes made to this pull request.

@rhettinger rhettinger merged commit 664fe39 into python:master Jun 1, 2019
DinoV pushed a commit to DinoV/cpython that referenced this pull request Jan 14, 2020
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.

9 participants