[TIP] Unit testing functions which call super

[Marcin Tustin]

Yes, that’s valid, but the problem (which I guess I didn’t specify) is that the base classes are both numerous and may be indirect. I don’t want to have to update static patch lists in tests every time a base class changes. This is a large, and evolving, codebase.

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

Like this? https://gist.github.com/hjwp/44210e3e164bbb1fed18



On 13 August 2014 19:11, Harry Percival <harry.percival at gmail.com<mailto:harry.percival at gmail.com>> wrote:
If you know what the parent class is in advance, could you use mock.patch to stub out the parent method?

On 13 August 2014 19:00, 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.

def foofunc(self):
    x= do_some_stuff()
    if x:
        return x
    return super(WhatevClass, self).foofunc()

Now, I don’t want to integration test the whole stack of super foofunc methods, just unit test that one, down to the super call.

I’ve accomplished this with, in my test (excuse the 8 leading spaces):

def setUp(self):
        self.method_archive = {}
        for klass in WhatevClass.__mro__[1:]:
            # we use the class as its own sentinel
            meth_or_klass = klass.__dict__.get('foofunc', klass)
            if meth_or_klass != klass:
                self.method_archive[klass] = meth_or_klass
                del klass.foofunc
        # now patch an arbitrary member of the mro to supply a dummy foofunc
        self.sentinel_klass = next(iter(self.method_archive))
        self.mock_sentinel = mock.MagicMock()
        self.sentinel_klass.foofunc = self.mock_sentinel


And corresponding unpatching in tearDown.

Is there any other approach which is standard, or objectively better?

Thanks,
Marcin

Marcin Tustin
Senior Software Engineer
________________________________


1111 Marcus Avenue
Lake Success, NY 11042
dealertrack.com<https://www.dealertrack.com/>
p 516.300.7072

dealertrack technologies™

Confidentiality Notice: This e-mail and any attachments may contain confidential, proprietary information of Dealertrack Technologies. It is intended solely for the named recipient(s) listed above and should be maintained in strictest confidence. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you have received this e-mail in error, please immediately notify the sender and delete this information from your computer and destroy any related paper copies. Unless otherwise expressly stated in the text of the e-mail, the addition of a typed name or initials to this e-mail does not (i) evidence an intent to sign the e-mail or (ii) constitute either (a) a signature or (b) consent to use electronic records or signatures in place of a writing or a handwritten signature


_______________________________________________
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



--
------------------------------
Harry J.W. Percival
------------------------------
Twitter: @hjwp
Mobile:  +44 (0) 78877 02511
Skype:         harry.percival



--
------------------------------
Harry J.W. Percival
------------------------------
Twitter: @hjwp
Mobile:  +44 (0) 78877 02511
Skype:         harry.percival
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20140813/ef09dd4c/attachment.htm>