On Tuesday, June 5, 2012 at 9:55 AM, Zach Mathew wrote: > 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. This is going to be slower than just unit testing get_context_data. > > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en.
-- You received this message because you are subscribed to the Google Groups "Django developers" group. 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.
