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... On 29 March 2014 23:55, Carl Meyer <c...@oddbird.net> wrote: > 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 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/53375D83.8060209%40oddbird.net > . > 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/CACFvh9_cPuJ5ffd4CoO4SaLKSbqBi06YgnTohR1yBnrd6NMNkA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
