[TIP] Unit testing functions which call super
Ned Batchelder
ned at nedbatchelder.com
Thu Aug 14 07:04:53 PDT 2014
"I guess you're not a django user"!! Harry is the author of Test-Driven
Development with Python (http://www.obeythetestinggoat.com/) which
features Django....
--Ned.
On 8/14/14 9:09 AM, Marcin Tustin wrote:
>
> I guess you're not a django user -- that would cut against the grain
> of the design of class based views. Inheritance IS the composition
> mechanism, and it works well, but it leads to this particular
> challenge with testing. In fact, I'm very satisfied with mocking super
> as a solution; it will only be in a minority of cases that anything
> more sophisticated is required.
>
> *From:*testing-in-python-bounces at lists.idyll.org
> [mailto:testing-in-python-bounces at lists.idyll.org] *On Behalf Of
> *Harry Percival
> *Sent:* Thursday, August 14, 2014 8:51 AM
> *Cc:* testing-in-python at lists.idyll.org
> *Subject:* Re: [TIP] Unit testing functions which call super
>
> Any mileage in doing the "prefer composition over inheritance" thing?
>
> On 14 August 2014 13:31, Marcin Tustin <Marcin.Tustin at dealertrack.com
> <mailto:Marcin.Tustin at dealertrack.com>> wrote:
>
> I can't share real code, but what I can tell you is that it's django
> code -- we've got a lot multiple inheritance going on with class based
> views. None of these methods are going to stop having super calls (or
> if they do, that will very much be the exception).
>
> As to behaviour-driven testing: I usually use that, and minimize
> mocks. With class based views, each class implements a different
> behaviour, and the inheritance hierarchy is fairly deep (at least
> three classes). Accordingly, each method really does need to be tested
> independently, because it is not that the method uses super to
> implement one behaviour; rather it is triggering the next behaviour,
> whatever that may be.
>
> *From:*David Stanek [mailto:dstanek at dstanek.com
> <mailto:dstanek at dstanek.com>]
> *Sent:* Wednesday, August 13, 2014 7:13 PM
> *To:* Marcin Tustin
> *Cc:* Ned Batchelder; 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 6:54 PM, Marcin Tustin
> <Marcin.Tustin at dealertrack.com <mailto:Marcin.Tustin at dealertrack.com>>
> wrote:
>
> 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.
>
> I think about my tests differently. I don't care how the feature is
> implemented all I care about is if it works. Mocking super means that
> you can't refactor your code without changing tests.
>
> Do you have any real code to share? I suspect that the method you had
> in your original post isn't real production code. But if I just look
> at that example the only thing I would mock is `do_some_stuff` because
> it's a collaborator.
>
> --
> 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
>
>
>
>
> --
> ------------------------------
> Harry J.W. Percival
> ------------------------------
> Twitter: @hjwp
> Mobile: +44 (0) 78877 02511
> Skype: harry.percival
>
>
>
> _______________________________________________
> testing-in-python mailing list
> 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/20140814/546f3d71/attachment.htm>
More information about the testing-in-python
mailing list