Hi Kazooie
LiveServerTestCase is a bit more lightweight than tools for using specific
drivers. It doesn't tie into Selenium, or Playwright, or any other
particular web browser library. Therefore I don't think there's going to be
any way for LiveServerTestCase to know what the curr
Hey,
Would it be possible to add a feature to LiveServerTestCase class to take a
screenshot of the web page and store the HTML somewhere in case of test
failure? I had to recently do this for one of my projects. This can be
helpful when debugging stuff for example when test fails in CI
.5.7/envs/work_env/lib/python3.5/site-packages/django/contrib/auth/models.py"
>>>> , line 23, in update_last_login
>>>> user.save(update_fields=['last_login'])
>>>> File
>>>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/p
>>> File
>>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/base.py"
>>> , line 708, in save
>>> force_update=force_update, update_fields=update_fields)
>>> File
>>> "/Users/ds/.
go/db/models/base.py"
>> , line 736, in save_base
>> updated = self._save_table(raw, cls, force_insert, force_update,
>> using, update_fields)
>> File
>> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/bas
rce_insert, force_update, using
> , update_fields)
> File
> "/Users/ds/.pyenv/versions/3.5.7/envs/work_env/lib/python3.5/site-packages/django/db/models/base.py"
> , line 805, in _save_table
> raise DatabaseError("Save with update_fields did not affect any rows.&q
id not affect any rows.")
django.db.utils.DatabaseError: Save with update_fields did not affect any
rows.
*Scenario:*
from django.test import TestCase, LiveServerTestCase
from paths.factories import UserFactory
class ATestClass(LiveServerTestCase):
@classmethod
def
re having a pain testing code that
> generating code. For instance
>
> class A(object):
> url = "some_url"
>
> test.py
>
> class TestingA(LiveserverTestcase):
> def test_a()
> "we can't override the url defined in obje
ating
code. For instance
class A(object):
url = "some_url"
test.py
class TestingA(LiveserverTestcase):
def test_a()
"we can't override the url defined in object A since its
initialized even before we a have access to self.liveserver_url"
On Saturday, O
please reopen the ticket, we are having a pain testing code that generating
code. For instance
class A(object):
url = "some_url"
test.py
class TestingA(LiveserverTestcase):
def test_a()
"we can't override the url defined in object A since its
initia
shion, though
> it's unclear to me if the use case of running LiveServerTestCase against an
> external server is a use case that justifies this.
>
> On Thursday, November 3, 2016 at 2:53:56 AM UTC-4, Andrew Wall wrote:
>>
>> Thanks everyone. I guess my Django skills aren't adv
, however, the environment variable also
isn't consulted anymore. This could be added back in some fashion, though
it's unclear to me if the use case of running LiveServerTestCase against an
external server is a use case that justifies this.
On Thursday, November 3, 2016 at 2:53:56 AM UTC-4, A
ng the same tests in his normal test environment. Based on
>>> the shell prompts in
>>> http://chimera.labs.oreilly.com/books/123400754/ch08.html#_creating_the_database_with_migrate
>>>
>>> I think he intends to have the database and code running on his
ning on his staging
> server while he runs his tests locally. He also avoids the
> TransactionTestCase truncation operations by shorting out the
> LiveServerTestCase setUp / tearDownClass.
>
> Simplest way?
> The simplest way I can think of to resolve the issue is to read the
> e
voids the
> TransactionTestCase truncation operations by shorting out the
> LiveServerTestCase setUp / tearDownClass.
>
> Simplest way?
> The simplest way I can think of to resolve the issue is to read the
> external liveserver out of os.env instead of sys.argv. Then you
LiveServerTestCase setUp / tearDownClass.
Simplest way?
The simplest way I can think of to resolve the issue is to read the
external liveserver out of os.env instead of sys.argv. Then you can follow
along exactly.
$ export EXTERNAL_SERVER='http://superlists-staging.ottg.eu'
$ python mana
eciate the Django framework.
>
> I noticed in the docs
> <https://docs.djangoproject.com/en/dev/releases/1.11/#liveservertestcase-binds-to-port-zero>
>
> for Django 1.11 that the *DJANGO_LIVE_TEST_SERVER_ADDRESS* environmental
> variable is slated to be removed, along w
Very much appreciate the Django framework.
I noticed in the docs
<https://docs.djangoproject.com/en/dev/releases/1.11/#liveservertestcase-binds-to-port-zero>
for Django 1.11 that the *DJANGO_LIVE_TEST_SERVER_ADDRESS* environmental
variable is slated to be removed, along wi
I'm inclined to make the changes, skip the deprecation, and react
appropriately if anyone raises a use case that can't be achieved with the
new "bind to port 0" technique.
I found a few more things that could be removed, for example the "manage.py
test --liveserver=..." option. Only creating a
I've never personally used DJANGO_LIVE_TEST_SERVER_ADDRESS for another
purpose than preventing port conflicts which binding to port 0 solves.
It always looked strange to me to rely on an environment variable to
achieve this. It feels like it was done this way to avoid introducing yet
another se
Wow : +8 −100 for that commit - that's a great re-factoring :)
On 17 June 2016 at 13:23, Tim Graham wrote:
> In IRC the other day, Donald pointed out
> https://www.dnorth.net/2012/03/17/the-port-0-trick/ and suggested that
> Django might be able to take advantage of that technique.
>
> I put tog
In IRC the other day, Donald pointed out
https://www.dnorth.net/2012/03/17/the-port-0-trick/ and suggested that
Django might be able to take advantage of that technique.
I put together a proof of concept that seems to work:
https://github.com/django/django/pull/6791
I'm wondering if anyone see
The argument that adding LiveServerTestCase with HTTPS as a separate tool
is easy - it is valid in this case, after my refactor has been merged.
The real use-case when I (and someone else may) need
HTTPSLiveServerTestCase is the one I wrote before:
- in a HTTPS-only application you can use
Hi,
On Monday 31 August 2015 21:24:53 Tim Graham wrote:
> however, there was previous discussion about adding SSL support to
> runserver met with mixed reaction [1] and it seems a little funny to me
> that we'd including a test SSL server and not a runserver solution.
>
> [1]
> https://groups.goo
n
On Monday, August 31, 2015 at 6:58:33 AM UTC-4, Jakub Gocławski wrote:
>
> Hi,
>
> Ticket: https://code.djangoproject.com/ticket/25328
>
> I made a proposal to include a LiveServerTestCase, which runs an HTTPS
> server instead of standard HTTP server. I've been asked to
Hi,
Ticket: https://code.djangoproject.com/ticket/25328
I made a proposal to include a LiveServerTestCase, which runs an HTTPS
server instead of standard HTTP server. I've been asked to get more
feedback for this idea.
If my refactor is merged I can release the test case as a separat
ber 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 ca
od 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 Tran
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,
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 LiveSer
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
Live
ework, 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
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 sw
s
> very weird effects when using `LiveServerTestCase`.
What version of Django are you using?
--
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 em
On Thu, Dec 19, 2013 at 7:36 PM, Harry Percival wrote:
> Thanks gang.
>
> @Russell, I assume you meant set MEDIA_URL = "/media/"
>
Heh. Now we're even on really dumb typos :-)
> That works if I do it in settings.py. Interestingly, it doesn't work if I
> try and do it via override_settings?
>
Thanks gang.
@Russell, I assume you meant set MEDIA_URL = "/media/"
That works if I do it in settings.py. Interestingly, it doesn't work if I
try and do it via override_settings?
On Thursday, 19 December 2013 08:16:59 UTC, Aymeric Augustin wrote:
>
> On 19 déc. 2013, at 02:14, Russell Keith-
On 19 déc. 2013, at 02:14, Russell Keith-Magee wrote:
> The upside - If you add MEDIA_ROOT='/media/' to settings.py, the problem goes
> away, because it gives the media layer something to match against that won't
> catch all files.
I hit that issue a month ago and filed
https://code.djangopro
s
> very weird effects when using `LiveServerTestCase`.
>
I presume this is just a typo, but for clarity - it's the other way around.
TestRunner forces DEBUG=False, with the theory being that you should be
testing "production" behaviour as much as possible.
> Minimal repro
Django's test runner overrides your settings to force DEBUG to be True,
which I understand the intention behind, but it is occasionally annoying.
One solution for those cases is to use `override_settings`, but that has
very weird effects when using `LiveServerTestCase`.
Minimal
On Tue, Aug 13, 2013 at 8:01 PM, Ramiro Morales wrote:
>
> Guys, I've updated the PR with further work on this:
>
> https://github.com/django/django/pull/1354
FYI This has landed on master with commit:
https://github.com/django/django/commit/e909ceae9b3e72b72e0a2baaa92bba9714f18cd2
Regards,
On Mon, Jul 15, 2013 at 1:16 PM, Ramiro Morales wrote:
> [...]
>
> I will be working further on the PR keeping all this design advice in
> mind.
Guys, I've updated the PR with further work on this:
https://github.com/django/django/pull/1354
Any feedback is welcome.
Thanks,
--
Ramiro Morale
irst step. The common denominator between
>> the core ability to serve files and staticfiles is the reliance on
>> conventions like STATIC_ROOT and STATIC_URL. If we can backscale
>> LiveServerTestCase to only do the core ability out of the box and
>> document the way to do
core ability to serve files and staticfiles is the reliance on
> conventions like STATIC_ROOT and STATIC_URL. If we can backscale
> LiveServerTestCase to only do the core ability out of the box and
> document the way to do it the staticfiles way, then I think we're on
> the right tr
tle good reason
> (e.g. only supporting LiveServerTestCase) then we **shouldn't** make
> the FSFilesHandler a new core component but just a implementation
> detail.
It would support it and the staticfiles handler but I agree with you on
that we should not be shipping something like FSFi
On 14.07.2013, at 15:16, Jannis Leidel wrote:
>
> On 14.07.2013, at 01:41, Ramiro Morales wrote:
>
>> Hi all,
>>
>> Ticket [1]8713 is tracking removing dependency of Django core on contrib
>> apps code.
>>
>> One of the action items enumerated
On 14.07.2013, at 01:41, Ramiro Morales wrote:
> Hi all,
>
> Ticket [1]8713 is tracking removing dependency of Django core on contrib
> apps code.
>
> One of the action items enumerated there is the fact that
> LiveServerTestCase makes use of django.contrib.staticfile
Hi all,
Ticket [1]8713 is tracking removing dependency of Django core on contrib
apps code.
One of the action items enumerated there is the fact that
LiveServerTestCase makes use of django.contrib.staticfiles' facilities.
I've opened ticket [2]20739 for it and have some work in progre
Julien, et. al.,
Seriously. Thank you. Amazing.
--
Justin Holmes
Head Instigator, SlashRoot Collective
SlashRoot: Coffee House and Tech Dojo
60 Main Street
New Paltz, NY 12561
845.633.8330
--
You received this message because you are subscribed to the Google Groups
"Django developers" gr
48 matches
Mail list logo
