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

Copying a Mock object breaks coverage #93

Closed
nedbat opened this issue Oct 7, 2010 · 5 comments
Closed

Copying a Mock object breaks coverage #93

nedbat opened this issue Oct 7, 2010 · 5 comments
Labels
bug Something isn't working

Comments

@nedbat
Copy link
Owner

nedbat commented Oct 7, 2010

Originally reported by n1ywb (Bitbucket: n1ywb, GitHub: n1ywb)


There's a strange trifecta of misbehavior occurring when I copy a Mock object. Following the copy, coverage seems to no longer be able to keep track of coverage. I've attached a trivial program that reproduces the bug. easy_install mock if you don't already have it.

It's possible the root cause is in Mock or some weird interaction between Mock and copy. But unless they're doing something very unholy, it seems like it should not break coverage.

Neither --timid nor --branch helps.

I just checked the latest thing out from bitbucket,

changeset: 932:8990640eecd9
tag: tip
user: Ned Batchelder ned@nedbatchelder.com
date: Sun Oct 03 13:21:17 2010 -0400
summary: A better way to figure out that the version number has a letter in it.

I chucked trace.c since I didn't have a compiler installed.

Coverage.py, version 3.5a1. http://nedbatchelder.com/code/coverage/3.5a1

Python 2.5.4

For what it's worth I also see this bug with the ancient version of coverage that comes with Eclipse PyDev.

jlaughlin@jlaughlin ~/tmp/coverage_bug
$ coverage run --timid test_bug.py -v && coverage report -m
copied a mock
I was called!
test_copy_mock (__main__.Test_1_copy_mock) ... ok
test_a_trivial_function (__main__.Test_2_a_trivial_function) ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.017s

OK
Name       Stmts   Miss  Cover   Missing
----------------------------------------
test_bug      14      3    79%   7, 12, 16

If you comment out line 11 in the program that copies the mock, coverage jumps to 100%.


@nedbat
Copy link
Owner Author

nedbat commented Oct 7, 2010

Original comment by n1ywb (Bitbucket: n1ywb, GitHub: n1ywb)


Here's an even smaller program that triggers the bug without using unittest.

@nedbat
Copy link
Owner Author

nedbat commented Oct 7, 2010

Original comment by n1ywb (Bitbucket: n1ywb, GitHub: n1ywb)


I opened a ticket in the Mock project as well: http://code.google.com/p/mock/issues/detail?id=48

@nedbat
Copy link
Owner Author

nedbat commented Oct 7, 2010

This is due to an infinite recursion in Mock.getattr. I've put a fix on the Mock ticket.

When the infinite recursion happens, the trace function doesn't get any indication of the stack unwinding through the 995 levels of infiniteness.

I'll leave this open to see if there's something we can do in coverage.py to at least indicate that something pathological is going on.

@nedbat
Copy link
Owner Author

nedbat commented Oct 13, 2010

Marius Gedminas had a good idea: "You could look at sys.gettrace() at the end: if it still points to your trace function, everything's probably fine, but if it got reset to None, warn the user." (http://nedbatchelder.com/blog/201010/surprising_getattr_recursion.html#comments)

@nedbat
Copy link
Owner Author

nedbat commented Nov 6, 2010

Changeset <<changeset faac189e0e45 (bb)>> adds Marius' warning idea. That's as good as I'm going to be able to make it.

@nedbat nedbat closed this as completed Nov 6, 2010
@nedbat nedbat added major bug Something isn't working labels Jun 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant