[TIP] Unit testing functions which call super

[Marcin Tustin]

It's not  question of terminology. What happens if I let the test call it's super is impossible to anticipate (but in practice will be some kind of exception). Even if it successfully calls the super methods, the output won't be defined by this code, but some other code, so I can't usefully test anything about it other than its type. If it doesn't work, then I have to deal with those exceptions, but then I can't very well distinguish between exceptions originating in the code I'm testing, and exceptions in the super methods. It's all the usual reasons for mocking out calls.

From: testing-in-python-bounces at lists.idyll.org [mailto:testing-in-python-bounces at lists.idyll.org] On Behalf Of Ned Batchelder
Sent: Wednesday, August 13, 2014 5:13 PM
To: testing-in-python at lists.idyll.org
Subject: Re: [TIP] Unit testing functions which call super

On 8/13/14 4:15 PM, Marcin Tustin wrote:

Yes: the reason is that I'm not writing an integration test, I'm writing a test to test this specific method. We need unit tests to test our individual units, and integration tests to test them together. It's not wise to rely only on integration tests (nor only on unit tests).

I say let the test call super(), and call it a unit test.  These terms can't be taken too literally.  Other than it being "the wrong kind" of test, what actual bad thing will happen if you call super() in your unit test?

This seems like a lot of effort to subvert Python's class machinery.  You'll end up with a mess, and probably more follow-on problems than you solve.

Probably the best approach is to refactor your code so that its more easily tested: if you are interested in what foofunc does without consideration of the base class, then create a function that doesn't call the base class.  Test that function.  Then you can call that function from another which does call the base class.

--Ned.


I actually do share the concern about over mocking (it's easy to mock so much that you test nothing), but it's important not to throw the baby out with the bathwater. Integration tests by their nature lack granularity to pinpoint problems (and yes, I realize it's possible and desirable to set up integration tests so that do point to where a detected problem originates, but it's still not a substitute for appropriate unit testing).

From: David Stanek [mailto:dstanek at dstanek.com]
Sent: Wednesday, August 13, 2014 2:35 PM
To: Marcin Tustin
Cc: testing-in-python at lists.idyll.org<mailto:testing-in-python at lists.idyll.org>
Subject: Re: [TIP] Unit testing functions which call super


On Wed, Aug 13, 2014 at 2:00 PM, Marcin Tustin <Marcin.Tustin at dealertrack.com<mailto:Marcin.Tustin at dealertrack.com>> wrote:
Hi All,

I've come across a method which I needed to add a unit test for, which calls super, e.g.


Is there any reason you can't call the parent's super?  In my view of testing you want to create an object, feed it input, and then check the output/side effect. I would stay away from mocking internals like this.

--
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.com




_______________________________________________

testing-in-python mailing list

testing-in-python at lists.idyll.org<mailto:testing-in-python at lists.idyll.org>

http://lists.idyll.org/listinfo/testing-in-python

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20140813/a47c1f45/attachment-0001.htm>