Re: LiveServerTestCase vs StaticLiveServerCase

[Carl Meyer]

On 03/29/2014 02:36 PM, Shai Berger wrote:
> On Saturday 29 March 2014 19:11:17 Harry Percival wrote:
>>
>> What I *am* saying is that, in my opinion, there's not much point in
>> LiveServerTestCase if it doesn't do static files.  So, to keep things
>> simple, it would be simpler to remove it, and just have on LiveServer test
>> class, that lives in .contrib if it has to...
>>
>> But maybe others would disagree?
>>
>> To explain a bit more -- what is LiveServerTestCase for?  It's to let you
>> run tests with (eg) selenium, against a "real" web server.  And one of the
>> most obvious reasons to do that is to test client-side stuff like
>> javascript, ie stuff that depends on static files.  And so that means that
>> you have to either run collectstatic before every test run, or switch to
>> StaticLiveServerCase.
>>
> 
> FWIW, I've been using LiveServerTestCase to test an app that, in some 
> circumstances, needs to send requests to other servers; in essence, mocking 
> those other servers. It's been very useful for this, and it does not require 
> any statics.
> 
> Granted, that is a fringe case, and the main use-case remains tests involving 
> real browsers. Just pointing out that a LiveServerTestCase with no support 
> for 
> statics does have real uses.

Contrib.staticfiles is an optional way of handling static assets in
Django. It probably is the most commonly-used way, but it is not
required. It is possible to write a fully-functional Django project that
uses static assets without using contrib.staticfiles to manage them.

IMO this is good enough reason for both LiveServerTestCase and
StaticLiveServerTestCase to exist.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/53375D83.8060209%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.7 make unit testing models harder

[Ryan Hiebert]

>
> I thought TextField did have a default, the empty string?
>
> Like every other field, the "default default" is None (NULL).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHQK9UdEK6x4Mb3eDqXd5f%3D9egzJp5A21UZYXAQJw8HRDw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.7 make unit testing models harder

[Harry Percival]

OK, I've now run into the problem IRL, and sure enough, it's different to
what i'm used to.  Am trying to overcome my knee-jerk reactions of "why did
it change! i hate it!".  ignoring that for a moment then:

One thing I did find surprising was that I'm going thru TDD in small steps
like this:

class Item(models.Model):
pass

- create migration 001-initial, with Item and auto-id

class Item(models.Model):
text = models.TextField()

- create migration 0002, adding the item field.  here's where we get into
the discussion of too many migrations, wanting to squash, etc etc etc.

leaving that aside for a moment, i was taken aback by this:

You are trying to add a non-nullable field 'text' to item without a default;
we can't do that (the database needs something to populate existing rows).
Please select a fix:
 1) Provide a one-off default now (will be set on all existing rows)
 2) Quit, and let me add a default in models.py

I thought TextField did have a default, the empty string?





On 29 March 2014 19:15, Harry Percival  wrote:

> I suspect you're probably right.  Having to run makemigrations in between
> making changes to model code and running tests isn't the end of the world i
> suppose.  Will know better what I'm talking about  when I've actually got
> to that part of the book...
>
>
> On 29 March 2014 18:23, Andrew Godwin  wrote:
>
>> No, there is no way to turn off migrations for tests - some of the core
>> tests won't work without them turned on, in fact, and adding that option
>> would be weird (why only tests? what would it do? how do you load data in
>> now initial_data is gone?). The only complaint I've seen - the one that
>> Bernie brought up originally, that it's "extra work" to run makemigrations
>> before each test run - doesn't really hold water with me, as the
>> alternative options mean you could run the tests and have them pass WITHOUT
>> HAVING THE RIGHT MIGRATIONS - and so you're not testing part of your
>> codebase.
>>
>> Hell, you can alias together makemigrations and test if you want, that'll
>> save you the typing. This might make a few more migrations than normal, but
>> you could quickly point out that squashmigrations exists to deal with this
>> problem and move on.
>>
>> Andrew
>>
>>
>> On Sat, Mar 29, 2014 at 9:42 AM, Harry Percival > > wrote:
>>
>>> Am just working on updating my book on TDD to django 1.7 based on the
>>> beta.   Currently half-way thru, not run into any problems because I don't
>>> use migrations until a later chapter, but when I do I will run into the
>>> same problems Bernie mentions.
>>>
>>> Will share more once I've finished the rewrites, but from what I see so
>>> far, I think I'd personally prefer to be able to run my tests without
>>> having to remember to call makemigrations every time.  some kind of
>>> customisable option?  either a command-line flag for the test runner, or
>>> maybe a setting in settings.py, eg MIGRATIONS_OFF_FOR_TESTS = True?
>>>
>>> personally i'd like the default to be true, but i can appreciate other
>>> people will have different workflows / assumptions.
>>>
>>>
>>>
>>>
>>> On Friday, 28 March 2014 16:48:52 UTC, Andrew Godwin wrote:
>>>
 Yes, --update is very risky if you run it on migrations that are
 already committed and pushed, but the main reason I left it out of 1.7 was
 complexity (because makemigrations is now much more intelligent, updating
 and adding a foreignkey into a migration might introduce a new dependency
 or force a new migration anyway). Given that we have the ability to safely
 squash large numbers of small migrations down into one with
 squashmigrations and distribute that to fix the many-small-migrations
 problem, I considered it pretty low priority, though I have a rough idea of
 how I could make it work (I'd have to load up the autodetector with the
 existing migrations already loaded in as a halfway state and then run it
 from there, which should produce the right result).

 Anyway, if you're retracting your original request, I'm happy to leave
 this for the 1.7 release; I don't think there's a good solution that Django
 core can implement effectively. This reminds me of when people used to ask
 me to automatically stop their developers writing conflicting migrations -
 the solution varies from company to company and often isn't technical but
 just education or communication.

 Andrew


 On Fri, Mar 28, 2014 at 4:46 AM, Bernie Sumption  wrote:

> South's `--update` also rolled the previous migration back, changed it
>> and then reapplied it to the current database.
>>
>
> OK, in that case I can very much see how it's useful for people who
> develop against a persistent database. That's probably most people.
>
> Anyway, the result of this thread for 

Ticket #22355: Humanize timedelta objects in Templates

[Anoop Thomas Mathew]

Hi All,

I've created a ticket along with the patch, tests and docs for a filter for 
humanizing timedelta objects on django templates.
Please find the concerned ticket here: 
https://code.djangoproject.com/ticket/22355

It would be awesome if any of the generous committers could review it and 
advice as needed.

Thanks,
Anoop

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/50717c0c-567b-440b-af59-798911f42a71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: LiveServerTestCase vs StaticLiveServerCase

[Shai Berger]

On Saturday 29 March 2014 19:11:17 Harry Percival wrote:
> 
> What I *am* saying is that, in my opinion, there's not much point in
> LiveServerTestCase if it doesn't do static files.  So, to keep things
> simple, it would be simpler to remove it, and just have on LiveServer test
> class, that lives in .contrib if it has to...
> 
> But maybe others would disagree?
> 
> To explain a bit more -- what is LiveServerTestCase for?  It's to let you
> run tests with (eg) selenium, against a "real" web server.  And one of the
> most obvious reasons to do that is to test client-side stuff like
> javascript, ie stuff that depends on static files.  And so that means that
> you have to either run collectstatic before every test run, or switch to
> StaticLiveServerCase.
> 

FWIW, I've been using LiveServerTestCase to test an app that, in some 
circumstances, needs to send requests to other servers; in essence, mocking 
those other servers. It's been very useful for this, and it does not require 
any statics.

Granted, that is a fringe case, and the main use-case remains tests involving 
real browsers. Just pointing out that a LiveServerTestCase with no support for 
statics does have real uses.

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4449879.WcngD07VJA%40deblack.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.7 make unit testing models harder

[Harry Percival]

I suspect you're probably right.  Having to run makemigrations in between
making changes to model code and running tests isn't the end of the world i
suppose.  Will know better what I'm talking about  when I've actually got
to that part of the book...


On 29 March 2014 18:23, Andrew Godwin  wrote:

> No, there is no way to turn off migrations for tests - some of the core
> tests won't work without them turned on, in fact, and adding that option
> would be weird (why only tests? what would it do? how do you load data in
> now initial_data is gone?). The only complaint I've seen - the one that
> Bernie brought up originally, that it's "extra work" to run makemigrations
> before each test run - doesn't really hold water with me, as the
> alternative options mean you could run the tests and have them pass WITHOUT
> HAVING THE RIGHT MIGRATIONS - and so you're not testing part of your
> codebase.
>
> Hell, you can alias together makemigrations and test if you want, that'll
> save you the typing. This might make a few more migrations than normal, but
> you could quickly point out that squashmigrations exists to deal with this
> problem and move on.
>
> Andrew
>
>
> On Sat, Mar 29, 2014 at 9:42 AM, Harry Percival 
> wrote:
>
>> Am just working on updating my book on TDD to django 1.7 based on the
>> beta.   Currently half-way thru, not run into any problems because I don't
>> use migrations until a later chapter, but when I do I will run into the
>> same problems Bernie mentions.
>>
>> Will share more once I've finished the rewrites, but from what I see so
>> far, I think I'd personally prefer to be able to run my tests without
>> having to remember to call makemigrations every time.  some kind of
>> customisable option?  either a command-line flag for the test runner, or
>> maybe a setting in settings.py, eg MIGRATIONS_OFF_FOR_TESTS = True?
>>
>> personally i'd like the default to be true, but i can appreciate other
>> people will have different workflows / assumptions.
>>
>>
>>
>>
>> On Friday, 28 March 2014 16:48:52 UTC, Andrew Godwin wrote:
>>
>>> Yes, --update is very risky if you run it on migrations that are already
>>> committed and pushed, but the main reason I left it out of 1.7 was
>>> complexity (because makemigrations is now much more intelligent, updating
>>> and adding a foreignkey into a migration might introduce a new dependency
>>> or force a new migration anyway). Given that we have the ability to safely
>>> squash large numbers of small migrations down into one with
>>> squashmigrations and distribute that to fix the many-small-migrations
>>> problem, I considered it pretty low priority, though I have a rough idea of
>>> how I could make it work (I'd have to load up the autodetector with the
>>> existing migrations already loaded in as a halfway state and then run it
>>> from there, which should produce the right result).
>>>
>>> Anyway, if you're retracting your original request, I'm happy to leave
>>> this for the 1.7 release; I don't think there's a good solution that Django
>>> core can implement effectively. This reminds me of when people used to ask
>>> me to automatically stop their developers writing conflicting migrations -
>>> the solution varies from company to company and often isn't technical but
>>> just education or communication.
>>>
>>> Andrew
>>>
>>>
>>> On Fri, Mar 28, 2014 at 4:46 AM, Bernie Sumption 
>>> wrote:
>>>
 South's `--update` also rolled the previous migration back, changed it
> and then reapplied it to the current database.
>

 OK, in that case I can very much see how it's useful for people who
 develop against a persistent database. That's probably most people.

 Anyway, the result of this thread for me is that I now consider my
 original request to be obsolete, as the "git clean" thing is a simple way
 of getting the behaviour I want for my own style of TDD without hacks.

 Thanks for your time.

 Bernie :o)

 --
 You received this message because you are subscribed to the Google
 Groups "Django developers" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to django-develop...@googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.

 Visit this group at http://groups.google.com/group/django-developers.
 To view this discussion on the web visit https://groups.google.com/d/
 msgid/django-developers/8e3ecf3c-aa05-4e3d-b905-
 3260b093e046%40googlegroups.com
 .

 For more options, visit https://groups.google.com/d/optout.

>>>
>>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this 

Re: LiveServerTestCase vs StaticLiveServerCase

[Harry Percival]

Well, neither, really, but, if anything, the latter.

- I don't think there's any bugs in StaticLiveServerCase.

- I have changed all my tests to use the new class.  it wasn't the end of
the world.

What I *am* saying is that, in my opinion, there's not much point in
LiveServerTestCase if it doesn't do static files.  So, to keep things
simple, it would be simpler to remove it, and just have on LiveServer test
class, that lives in .contrib if it has to...

But maybe others would disagree?

To explain a bit more -- what is LiveServerTestCase for?  It's to let you
run tests with (eg) selenium, against a "real" web server.  And one of the
most obvious reasons to do that is to test client-side stuff like
javascript, ie stuff that depends on static files.  And so that means that
you have to either run collectstatic before every test run, or switch to
StaticLiveServerCase.






On 29 March 2014 18:10, Ramiro Morales  wrote:

> On Sat, Mar 29, 2014 at 1:26 PM, Harry Percival
>  wrote:
>
> >
> > [...]
> >
> > But I just wanted to express the fact that it feels a little
> > counter-intuitive.   I don't know enough to weigh how important it is to
> > remove a dependency on a contrib app from the testcases framework, but,
> as a
> > user, having to remember that i need to run `collectstatic` before all my
> > tests will pass is a bit weird. collectstatic is something i do on
> servers,
> > not on my local dev box. and LiveServerTestCase isn't much use without
> > working static files.
>
> Are you saying that you need to run collectstatic before all your tests
> when you make your test cases inherit from StaticLiveServerCase instead
> of LiveServerTestCase?. Because if so, that's a bug I'd need to fix because
> that's not the intended behavior and I'm the one behind this change.
>
> Or are you saying that you don't want to bother to edit your tests code
> to replace StaticLiveServerCase with LiveServerTestCase as part of your
> migration to 1.7?
>
> Regards,
>
> --
> Ramiro Morales
> @ramiromorales
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/SYktTEJXWc8/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAO7PdF9xTf7rtLtemaSHUXeX8eqc7oR7wD-%3DZyL9LedjQ7ZxRA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
--
Harry J.W. Percival
--
Twitter: @hjwp
Mobile:  +44 (0) 78877 02511
Skype: harry.percival

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACFvh99crRT5Ne-6pZhUAQQ7_vC9PcBbRqxNi%3D0UJHSifpkWgg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.7 make unit testing models harder

[Andrew Godwin]

No, there is no way to turn off migrations for tests - some of the core
tests won't work without them turned on, in fact, and adding that option
would be weird (why only tests? what would it do? how do you load data in
now initial_data is gone?). The only complaint I've seen - the one that
Bernie brought up originally, that it's "extra work" to run makemigrations
before each test run - doesn't really hold water with me, as the
alternative options mean you could run the tests and have them pass WITHOUT
HAVING THE RIGHT MIGRATIONS - and so you're not testing part of your
codebase.

Hell, you can alias together makemigrations and test if you want, that'll
save you the typing. This might make a few more migrations than normal, but
you could quickly point out that squashmigrations exists to deal with this
problem and move on.

Andrew


On Sat, Mar 29, 2014 at 9:42 AM, Harry Percival wrote:

> Am just working on updating my book on TDD to django 1.7 based on the
> beta.   Currently half-way thru, not run into any problems because I don't
> use migrations until a later chapter, but when I do I will run into the
> same problems Bernie mentions.
>
> Will share more once I've finished the rewrites, but from what I see so
> far, I think I'd personally prefer to be able to run my tests without
> having to remember to call makemigrations every time.  some kind of
> customisable option?  either a command-line flag for the test runner, or
> maybe a setting in settings.py, eg MIGRATIONS_OFF_FOR_TESTS = True?
>
> personally i'd like the default to be true, but i can appreciate other
> people will have different workflows / assumptions.
>
>
>
>
> On Friday, 28 March 2014 16:48:52 UTC, Andrew Godwin wrote:
>
>> Yes, --update is very risky if you run it on migrations that are already
>> committed and pushed, but the main reason I left it out of 1.7 was
>> complexity (because makemigrations is now much more intelligent, updating
>> and adding a foreignkey into a migration might introduce a new dependency
>> or force a new migration anyway). Given that we have the ability to safely
>> squash large numbers of small migrations down into one with
>> squashmigrations and distribute that to fix the many-small-migrations
>> problem, I considered it pretty low priority, though I have a rough idea of
>> how I could make it work (I'd have to load up the autodetector with the
>> existing migrations already loaded in as a halfway state and then run it
>> from there, which should produce the right result).
>>
>> Anyway, if you're retracting your original request, I'm happy to leave
>> this for the 1.7 release; I don't think there's a good solution that Django
>> core can implement effectively. This reminds me of when people used to ask
>> me to automatically stop their developers writing conflicting migrations -
>> the solution varies from company to company and often isn't technical but
>> just education or communication.
>>
>> Andrew
>>
>>
>> On Fri, Mar 28, 2014 at 4:46 AM, Bernie Sumption 
>> wrote:
>>
>>> South's `--update` also rolled the previous migration back, changed it
 and then reapplied it to the current database.

>>>
>>> OK, in that case I can very much see how it's useful for people who
>>> develop against a persistent database. That's probably most people.
>>>
>>> Anyway, the result of this thread for me is that I now consider my
>>> original request to be obsolete, as the "git clean" thing is a simple way
>>> of getting the behaviour I want for my own style of TDD without hacks.
>>>
>>> Thanks for your time.
>>>
>>> Bernie :o)
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>>
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/django-developers/8e3ecf3c-aa05-4e3d-b905-
>>> 3260b093e046%40googlegroups.com
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> 

Re: LiveServerTestCase vs StaticLiveServerCase

[Ramiro Morales]

On Sat, Mar 29, 2014 at 1:26 PM, Harry Percival
 wrote:

>
> [...]
>
> But I just wanted to express the fact that it feels a little
> counter-intuitive.   I don't know enough to weigh how important it is to
> remove a dependency on a contrib app from the testcases framework, but, as a
> user, having to remember that i need to run `collectstatic` before all my
> tests will pass is a bit weird. collectstatic is something i do on servers,
> not on my local dev box. and LiveServerTestCase isn't much use without
> working static files.

Are you saying that you need to run collectstatic before all your tests
when you make your test cases inherit from StaticLiveServerCase instead
of LiveServerTestCase?. Because if so, that's a bug I'd need to fix because
that's not the intended behavior and I'm the one behind this change.

Or are you saying that you don't want to bother to edit your tests code
to replace StaticLiveServerCase with LiveServerTestCase as part of your
migration to 1.7?

Regards,

-- 
Ramiro Morales
@ramiromorales

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAO7PdF9xTf7rtLtemaSHUXeX8eqc7oR7wD-%3DZyL9LedjQ7ZxRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations in Django 1.7 make unit testing models harder

[Harry Percival]

Am just working on updating my book on TDD to django 1.7 based on the 
beta.   Currently half-way thru, not run into any problems because I don't 
use migrations until a later chapter, but when I do I will run into the 
same problems Bernie mentions.

Will share more once I've finished the rewrites, but from what I see so 
far, I think I'd personally prefer to be able to run my tests without 
having to remember to call makemigrations every time.  some kind of 
customisable option?  either a command-line flag for the test runner, or 
maybe a setting in settings.py, eg MIGRATIONS_OFF_FOR_TESTS = True?

personally i'd like the default to be true, but i can appreciate other 
people will have different workflows / assumptions.



On Friday, 28 March 2014 16:48:52 UTC, Andrew Godwin wrote:
>
> Yes, --update is very risky if you run it on migrations that are already 
> committed and pushed, but the main reason I left it out of 1.7 was 
> complexity (because makemigrations is now much more intelligent, updating 
> and adding a foreignkey into a migration might introduce a new dependency 
> or force a new migration anyway). Given that we have the ability to safely 
> squash large numbers of small migrations down into one with 
> squashmigrations and distribute that to fix the many-small-migrations 
> problem, I considered it pretty low priority, though I have a rough idea of 
> how I could make it work (I'd have to load up the autodetector with the 
> existing migrations already loaded in as a halfway state and then run it 
> from there, which should produce the right result).
>
> Anyway, if you're retracting your original request, I'm happy to leave 
> this for the 1.7 release; I don't think there's a good solution that Django 
> core can implement effectively. This reminds me of when people used to ask 
> me to automatically stop their developers writing conflicting migrations - 
> the solution varies from company to company and often isn't technical but 
> just education or communication.
>
> Andrew
>
>
> On Fri, Mar 28, 2014 at 4:46 AM, Bernie Sumption 
>  > wrote:
>
>> South's `--update` also rolled the previous migration back, changed it 
>>> and then reapplied it to the current database.
>>>
>>
>> OK, in that case I can very much see how it's useful for people who 
>> develop against a persistent database. That's probably most people.
>>
>> Anyway, the result of this thread for me is that I now consider my 
>> original request to be obsolete, as the "git clean" thing is a simple way 
>> of getting the behaviour I want for my own style of TDD without hacks.
>>
>> Thanks for your time.
>>
>> Bernie :o)
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/8e3ecf3c-aa05-4e3d-b905-3260b093e046%40googlegroups.com
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a2897318-ec81-4acd-b201-2591042db1a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

LiveServerTestCase vs StaticLiveServerCase

[Harry Percival]

Just updating my book to using the django 1.7 beta.   I use 
LiveServerTestCase a lot.

I used to rely on the fact that LiveServerTestCase "magically" serves 
static files from app folders.  I see the default functionality is that 
this no longer works, but I can get it by switching to 
StaticLiveServerTestCase.  great, glad to see that was built for backwards 
compatibility, I'll switch to using that, so no immediate problem.  i am, 
as always, eternally gratefully to everyone involved for their 
thoughtfulness.

But I just wanted to express the fact that it feels a little 
counter-intuitive.   I don't know enough to weigh how important it is to 
remove a dependency on a contrib app from the testcases framework, but, as 
a user, having to remember that i need to run `collectstatic` before all my 
tests will pass is a bit weird. collectstatic is something i do on servers, 
not on my local dev box. and LiveServerTestCase isn't much use without 
working static files.

So I guess I'm saying, how about just moving LiveServerTestCase into 
contrib, and merging it with StaticLiveServerTestCase??


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c0868046-2147-486b-8c2c-06f3cd5ca8af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.