I'm not suggesting that CBVs make it harder to test (I actually think it should be no different because the tests should avoid being implementation specific). I just feel that the pattern of testing/refactoring is different than the typical TDD approach (one could argue that this is not necessarily a bad thing - but that's a whole another can of worms).
I think Marc makes a very valid point about CBVs being well suited for unit testing. This I agree with. But I typically try to avoid unit testing as much as possible in favour of a more "outside-in" approach (ie. integration testing). For example, I would avoid unit testing the "get_context_data" method on a CBV and instead have a test that performs a request on the view and tests the context variables. I'm beginning to think that the divisions on this issue among developers might be tied to development style. This would explain why some people love them and some people hate them. On Tuesday, June 5, 2012 2:02:14 AM UTC-4, Marc Tamlyn wrote: > > 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/-/_9hq-OjYc3wJ. 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.
