238 / 478
return
redirect
(
list_
)
return
render
(
request
,
'list.html'
, {
'list'
:
list_
,
"form"
:
form
})
And we still have full passes:
Ran 24 tests in 0.111s
OK
and
Ran 3 tests in 14.367s
OK
Great! Our two views are now looking very much like “normal” Django views: they take
information from a user’s request, combine it with some custom logic or information
from the URL (
list_id
), pass it to a form for validation and possible saving, and then
redirect or render a template.
Forms and validation are really important in Django, and in web programming in gen‐
eral, so let’s see if we can’t make a slightly more complicated one in the next chapter.
Tips
Thin views
If you find yourself looking at complex views, and having to write a lot of tests for
them, it’s time to start thinking about whether that logic could be moved elsewhere:
possibly to a form, like we’ve done here. Another possible place would be a custom
method on the model class. And—once the complexity of the app demands it—out
of Django-specific files and into your own classes and functions, that capture your
core business logic.
Each test should test one thing
The heuristic is to be suspicious if there’s more than one assertion in a test. Some‐
times two assertions are closely related, so they belong together. But often your first
draft of a test ends up testing multiple behaviours, and it’s worth rewriting it as
several tests. Helper functions can keep them from getting too bloated.
210
|
Chapter 11: A Simple Form