[TIP] Testing django redirects/render

andrea crotti andrea.crotti.0 at gmail.com
Tue Apr 23 10:25:02 PDT 2013

2013/4/23 Carl Meyer <carl at oddbird.net>

> Hi andrea,
> On 04/23/2013 09:59 AM, andrea crotti wrote:
> > Now I would also like to unit test the render and redirects, but I am a
> > bit in trouble because for example redirects try to do a reverse
> > routing, which then fails in the unit tests.
> >
> > One way would be to mock redirect and just check that it gets called
> > with the right arguments which would already be good enough, but maybe
> > there are other ways?
> Well, for a middle ground you could create a test URLconf and
> temporarily set ROOT_URLCONF for the duration of the test. This isolates
> your test from your real urlconf, but not from all the url-routing code.
> In practice I think this is often the worst of both worlds; it won't be
> any faster than using the real urlconf, but like mocking it introduces
> the possibility of divergence. (Same discussion applies to template
> rendering: replace "ROOT_URLCONF" with "TEMPLATE_DIRS" and "test
> urlconf" with "test templates directory"). So I think your best choices
> are to just mock redirect/render for a unit test, or only test your view
> functions via integration tests.
> I tend to do the latter. View functions (or controllers) are the
> "integration" level of a web app. (In the terms Gary Bernhardt used in
> his Boundaries talk at PyCon, they are the "imperative shell" as opposed
> to the "functional core"). I find the best mileage in just minimizing
> the amount of code (and especially the number of conditionals) at this
> level, and then covering this code via integration tests only, rather
> than brittle mock-heavy unit tests.
Yes well but the problem is that we have really a lot of logic in the
django views now, which is probably wrong but while we change that I should
add tests for it.
I think I'll go for the mocking strategy then, it's very easy anyway and I
can at least check all the logic and assume that the redirect/render do the
right job at this point.

> > I don't really want to use the django client, because it's too slow and
> > they would not be unit tests anymore. In plus for integration tests I
> > would rather spend time with selenium, that at least really checks the
> > whole flow.
> I find value in Python-level integration tests (though I prefer WebTest
> to the Django test client) -- they are still an order of magnitude
> faster than Selenium tests. Though the balance there does depend on how
> heavy the client-side behavior is in the flows you need to test.

Yes I would also like to add these kind of tests, but since we have no
selenium tests so far, I think those are more important, and as a third
thing I would probably try to add these kind of tests as well..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20130423/58a895e3/attachment.htm>

More information about the testing-in-python mailing list