Great ideas! I've started moving some of my logic that I had in
admin.py and views.py into model.py and things are already starting to
look easier in terms of testing.
My only real hurdle now is testing validation logic on the admin pages
and the form creation logic that is the main page to the a
On Thu, Jul 16, 2009 at 3:16 PM, Jumpfroggy wrote:
> You could put all these functions into the
> models.py file if you wanted, you'd just end up with huge models.py
> objects, and you might also run into cases where there is not an
> obvious place to put a bit of business logic. Not every busine
> besides the testing issues (which are certainly a heated debate!), i have to
> say that my Django projects became far better organized and a lot more
> flexible when i learned to put most of the code on the models, and not on the
> views.
This is a pretty interesting topic. Coming from a PH
On Jul 16, 1:35 pm, Javier Guerra wrote:
> On Thu, Jul 16, 2009 at 9:27 AM, Joshua Russo wrote:
> > What are some examples of mutating operations (and other operations
> > for that matter) that you use in your models?
>
> the most obvious are:
>
> - 'calculated' fields. the first example is the
On Thu, Jul 16, 2009 at 9:27 AM, Joshua Russo wrote:
> What are some examples of mutating operations (and other operations
> for that matter) that you use in your models?
the most obvious are:
- 'calculated' fields. the first example is the __unicode__() method,
but lots others, like multiplyin
Whenever I do the same query in a couple of different views, I try to
pull it out into a manager method[1]. For instance, get all the
stories that are marked published from the last two days. I would make
this a method on the manager so I can reuse it other places. Then I
write a test for that man
> besides the testing issues (which are certainly a heated debate!), i have to
> say that my Django projects became far better organized and a lot more
> flexible when i learned to put most of the code on the models, and not on the
> views.
I find this really interesting because I wanted to pu
On Jul 16, 1:20 am, Joshua Russo wrote:
> I'm in the process of implementing testing (both doc tests and unit
> tests) though I'm having some conceptual difficulty. I'm not sure how
> far to take the testing. I'm curious what people concider an
> appropriate level of testing.
>
> This thought str
Joshua Russo wrote:
> This thought struck me most when I was going through the testing
> documentation, in the section regarding the testing of models. It
> seems to me that very little logic generally goes into the model
> classes. At least for me, I have far more logic in admin.py and
> views.py
Basically, you want to test anything that might break if another part
of the code is changed that interacts with it, might break if the
application takes an alternative flow (maybe finally hits the 'else'
of that if/else statement), or could possibly receive invalid input.
Unfortunately, t
> I'm in the process of implementing testing (both doc tests and unit
> tests) though I'm having some conceptual difficulty. I'm not sure how
> far to take the testing. I'm curious what people concider an
> appropriate level of testing.
Uh oh, be ready for a huge thread. This is one of those une
I'm in the process of implementing testing (both doc tests and unit
tests) though I'm having some conceptual difficulty. I'm not sure how
far to take the testing. I'm curious what people concider an
appropriate level of testing.
This thought struck me most when I was going through the testing
doc
12 matches
Mail list logo
