Copying a Mock object breaks coverage

Issue #93 resolved
n1ywb created an issue

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 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., version 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.

<pre>jlaughlin@jlaughlin ~/tmp/coverage_bug $ coverage run --timid -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%.

Comments (7)

  1. Ned Batchelder repo owner

    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 to at least indicate that something pathological is going on.

  2. Log in to comment