There is a plan to do some work on the docs at the djangocon sprints - in 
particular trying to get some examples of when you 'could' and when you 
'should not' use the generic CBVs.

With regards to Zach's point about TDD testing - some of that may simply be 
familiarity. I don't know about you but it would have been very difficult 
for me to get into successfully TDDing a functional view until I'd written 
several dozen views and knew what the pattern is. You can still test the 
CBV top to bottom, exactly as you would with a function based view. Yes 
there may be some shift to conventions, but that will come with familiarity.

I think part of the important difference is that when you look at a CBV for 
the purposes of unit testing it, you feel very quickly that you should be 
testing the individual methods. This is actually really nice and gives a 
lot more branch-coverage without rerunning the same 4 database queries 
every time for variables which aren't used. Without CBVs a complex view can 
easily extend over 50 or so lines, whereas it's more natural to split this 
up and test the sections independently with a Class based system. I know in 
general we should be 'writing less view code' and pushing the logic 
elsewhere, but that depends on what that logic is - for example the view 
layer needs to decide whether to return JSON or HTML depending on certain 
headers in the request, and that is more easily testable as an overridden 
render to response method than as the last 4 lines of a 50 line view.

Marc

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/VZsGxxTYyoIJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to