This is another place where I personally feel the mocking is excessive. I can see the rationale that we're not trying to test cmp, but I don't think that's the case. I'm a fan of testing the behavior of things more than the structure. Behaviorally (I don't think that's actually a word), we want to assert the correct comparison between two units. We know that unit A is greater than unit B, so the test should verify that. What's being tested here is more of a blueprint of the structure of the code. It's not that unit A is greater than B, it's testing that the code took path X to try to get to that answer.

Put another way, if a unit test verifies the behavior and expectation of a method, then it's a built in regression test. If we are verifying that unit comparisons perform mathematically as we expect them to, then we could theoretically gut the __cmp__ implementation and replace it with something entirely different that doesn't leverage cmp(). In those cases, the unit tests should continue to pass, assuming we've honored the mathematical contract of what the method should do. But with this test, it would fail. Not necessarily because the new implementation didn't function correctly, but simply because it didn't use a particular way of getting to the end value.

This makes for a good academic example to talk about theory. I don't (necessarily, some times there may be cases) want to test what a computation did to arrive at the answer, just that the answer is correct.

Let me be clear, I'm not trying to make it sound like this is a huge problem. It's something I'd like you to at least consider a bit, but this conversation is more in the context of sitting around at lunch chatting about software engineering theory than it is me saying this is a blocker in a pull request.