LiveServerTestCase vs StaticLiveServerCase
956 views
Skip to first unread message
Harry Percival
Mar 29, 2014, 12:26:53 PM3/29/14
to django-d...@googlegroups.com
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??
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??
Ramiro Morales
Mar 29, 2014, 2:10:56 PM3/29/14
to django-d...@googlegroups.com
On Sat, Mar 29, 2014 at 1:26 PM, Harry Percival
<harry.p...@gmail.com> wrote:
>
> [...]
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
<harry.p...@gmail.com> 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
> 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.
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
Harry Percival
Mar 29, 2014, 3:11:17 PM3/29/14
to Django Developers group
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAO7PdF9xTf7rtLtemaSHUXeX8eqc7oR7wD-%3DZyL9LedjQ7ZxRA%40mail.gmail.com.
--
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-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.
For more options, visit https://groups.google.com/d/optout.
--
------------------------------
Harry J.W. Percival
------------------------------
Twitter: @hjwp
Mobile: +44 (0) 78877 02511
Skype: harry.percival
Shai Berger
Mar 29, 2014, 4:36:33 PM3/29/14
to django-d...@googlegroups.com
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
>
> 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.
>
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.
Carl Meyer
Mar 29, 2014, 7:55:47 PM3/29/14
to django-d...@googlegroups.com
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
Harry Percival
Mar 30, 2014, 8:02:07 AM3/30/14
to Django Developers group
In that case, maybe the question is: which should be the default?
Given that, as you say, most people use staticfiles, it feels to me like the test case in which static files "just work", without having to remember to run `collectstatic` before each test run, would feel like a good default.--
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-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/53375D83.8060209%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.
Carl Meyer
Mar 31, 2014, 12:07:50 AM3/31/14
to django-d...@googlegroups.com
On 03/30/2014 06:02 AM, Harry Percival wrote:
> In that case, maybe the question is: which should be the default?
>
> Given that, as you say, most people use staticfiles, it feels to me like
> the test case in which static files "just work", without having to
> remember to run `collectstatic` before each test run, would feel like a
> good default.
>
> More advanced users who are managing their static assets totally
> differently -- on a CDN, say -- can then use the more restrictive
> LiveServerTestCase if they want to. Although the default test case
> would still work just fine for them.
>
> Maybe there's a parallel with TestCase and TransactionTestCase? The
> first will work in 90% of cases, the latter you can use if you have some
> more specialised requirements...
What does "default" mean in this case? In what way is one of these more
> In that case, maybe the question is: which should be the default?
>
> Given that, as you say, most people use staticfiles, it feels to me like
> the test case in which static files "just work", without having to
> remember to run `collectstatic` before each test run, would feel like a
> good default.
>
> More advanced users who are managing their static assets totally
> differently -- on a CDN, say -- can then use the more restrictive
> LiveServerTestCase if they want to. Although the default test case
> would still work just fine for them.
>
> Maybe there's a parallel with TestCase and TransactionTestCase? The
> first will work in 90% of cases, the latter you can use if you have some
> more specialised requirements...
"default" than the other? Neither one is used by the default project
template.
In terms of code location, it makes sense that the "basic" version lives
in core, and the version that relies on contrib.staticfiles extends the
core version and lives in contrib.staticfiles.
Maybe there's a documentation patch you're thinking of to direct people
more clearly to StaticLiveServerTestCase? Currently it looks like that
only happens in the "changed in Django 1.7" note at the bottom of that
section.
Carl
Reply all
Reply to author
Forward
0 new messages