<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">2013/4/23 Carl Meyer <span dir="ltr"><<a href="mailto:carl@oddbird.net" target="_blank">carl@oddbird.net</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi andrea,<br>
<div class="im"><br>
On 04/23/2013 09:59 AM, andrea crotti wrote:<br>
> Now I would also like to unit test the render and redirects, but I am a<br>
> bit in trouble because for example redirects try to do a reverse<br>
> routing, which then fails in the unit tests.<br>
><br>
> One way would be to mock redirect and just check that it gets called<br>
> with the right arguments which would already be good enough, but maybe<br>
> there are other ways?<br>
<br>
</div>Well, for a middle ground you could create a test URLconf and<br>
temporarily set ROOT_URLCONF for the duration of the test. This isolates<br>
your test from your real urlconf, but not from all the url-routing code.<br>
In practice I think this is often the worst of both worlds; it won't be<br>
any faster than using the real urlconf, but like mocking it introduces<br>
the possibility of divergence. (Same discussion applies to template<br>
rendering: replace "ROOT_URLCONF" with "TEMPLATE_DIRS" and "test<br>
urlconf" with "test templates directory"). So I think your best choices<br>
are to just mock redirect/render for a unit test, or only test your view<br>
functions via integration tests.<br>
<br>
I tend to do the latter. View functions (or controllers) are the<br>
"integration" level of a web app. (In the terms Gary Bernhardt used in<br>
his Boundaries talk at PyCon, they are the "imperative shell" as opposed<br>
to the "functional core"). I find the best mileage in just minimizing<br>
the amount of code (and especially the number of conditionals) at this<br>
level, and then covering this code via integration tests only, rather<br>
than brittle mock-heavy unit tests.<br>
<div class="im"><br></div></blockquote><div><br></div><div style>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.<br>
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.</div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> I don't really want to use the django client, because it's too slow and<br>
> they would not be unit tests anymore. In plus for integration tests I<br>
> would rather spend time with selenium, that at least really checks the<br>
> whole flow.<br>
<br>
</div>I find value in Python-level integration tests (though I prefer WebTest<br>
to the Django test client) -- they are still an order of magnitude<br>
faster than Selenium tests. Though the balance there does depend on how<br>
heavy the client-side behavior is in the flows you need to test.<br></blockquote><div> </div><div style>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..</div>
</div></div></div>