Re: Django's CVB - Roadmap?

[Zach Mathew]

On Tuesday, June 5, 2012 10:12:45 AM UTC-4, dstufft wrote:
>
> On Tuesday, June 5, 2012 at 9:55 AM, Zach Mathew wrote:
>
> 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. 
>

That's a cost I'm willing to accept. The big advantage is that I could 
completely change the implementation of my view without having to rewrite 
my tests (ie. the tests are not implementation specific).

We might be getting sidetracked into a debate about testing methodologies, 
so let me reiterate that the general point I'm trying to make here is just 
that CBVs might be more suitable for a different style of 
programming/testing than the tdd top down/outside-in testing approach. And 
this might be the cause of some people's frustrations with it.
 

-- 
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/-/T4Dr8oCinC8J.
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.

Re: Django's CVB - Roadmap?

[Zach Mathew]

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.

Re: Django's CVB - Roadmap?

[Zach Mathew]

Glad to see this debate happening, because for a long time I felt like I 
was the only one who had issues with CBVs. I forced myself to use CBVs 
(custom and generics) on two major projects and I'm still struggling to see 
the real value in them.

Luke's post did an excellent job of articulating the issues, so I won't 
bother repeating the same arguments.

However, one of the things I find with CBVs is that it encourages a 
programming style that doesn't seem to go well with the TDD approach (at 
least in my opinion):

With FBVs, I would start writing the code for my view, satisfying the test, 
then going back and refactoring the view code by looking for commonalities 
with other views (Write code > Pass Test > Refactor)

With CBVs, I tend to start by searching for an appropriate parent/base 
class to subclass, then writing my custom view code and satisfying the 
test. I see this as forcing the refactoring first before writing custom 
code (Refactor > Write code > Pass Test)

Not sure if anyone else feels the same way, but it's good to hear all the 
different perspectives on this.

-- 
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/-/dMym_nPg2T0J.
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.

Re: Django's CVB - Roadmap?

[Zach Mathew]

Glad to see this debate happening, because for a long time I felt like I 
was the only one who had issues with CBVs. I forced myself to use CBVs 
(custom and generics) on two major projects and I'm still struggling to see 
the real value in them.

Luke's post did an excellent job of articulating the issues, so I won't 
bother repeating the same arguments.

However, one of the things I find with CBVs is that it encourages a 
programming style that doesn't seem to go well with the TDD approach (at 
least in my opinion):

With FBVs, I would start writing the code for my view, satisfying the test, 
then going back and refactoring the view code by looking for commonalities 
with other views (Write code > Pass Test > Refactor)

With CBVs, I tend to start by searching for an appropriate parent/base 
class to subclass, then writing my custom view code and satisfying the 
test. I see this as forcing the refactoring first before writing custom 
code (Refactor > Write code > Pass Test)

Not sure if anyone else feels the same way, but it's good to hear all the 
different perspectives on this.

-- 
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/-/jMkryR-q8YcJ.
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.

Re: Why CharFields don't have default=None?

[Zach Mathew]

Russell Keith-Magee  wrote:
> Django has made a value judgement that an empty field in a form will
> be interpreted as an empty string. If you don't like this default
> behaviour, you can override it at the form level.

That makes sense for forms (where input is coming from the end user),
but why does Django have to make this judgment on models (where input
is coming from python code or has been cleaned by python code)?

I too find this behaviour odd because Django is creating a default
value for my model charfield when I have not specified a default. If I
wanted empty string to be the default I would have put default='' in
the charfield definition.

--
Zach

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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=.