Re: How to test patch

[Dominic Rodger]

Another long time user here (at some point I'd love to make the jump to 
contributor, just need to find more time) - out of interest, is there a 
reason we don't use Travis? I wonder if that might help those with commit 
access, since pre-tested pull requests would mean you could have confidence 
that the tests at least pass. Apologies if this has been discussed before 
(there are a few contributors to this group called Travis, which made 
searching a bit tricky!).

Dom

On Sunday, October 28, 2012 2:11:56 AM UTC, ptone wrote:
>
> Thanks Jan for the contributions.
>
> I'll add a couple bits to Russ's excellent reply.
>
> I generally will run just a specific test, or a subset of the tests while 
> developing the patch initially, this is much faster and can let you iterate 
> much more quickly.
>
> Julien has put together a great tool for running the full test suite  - 
> allowing you to test more python versions including the GIS stuff:
>
> https://github.com/jphalip/djangocore-box
>
> Finally - note that for some work, you will occasionally hit test 
> interaction issues, where global state causes unintended failures to happen 
> in apparently unrelated tests. Hopefully this won't happen, but if it does 
> and you're stumped, reach out for help.
>
> -Preston
>
> On Saturday, October 27, 2012 4:33:35 PM UTC-7, Jan Bednařík wrote:
>>
>> Hi all,
>>
>> I'm using Django for more than four years and last week I started 
>> contributing.
>>
>> In docs about contributing I didn't find how detailed should be my 
>> testing while I'm writing or reviewing patch? Is enough to run tests only 
>> for patched module? Or should I run full test suite for each patch? Which 
>> combinations of Python versions and database engines are mandatory?
>>
>> So far I was running Python 2.7 & SQLite3 for development/review testing 
>> of module. Python 3.2 & SQLite3, Python 2.7 & PostgreSQL for patched module 
>> and in the end Python 2.7 & SQLite3 full test suite (with selenium, etc.). 
>> Is this workflow ok?
>>
>> Jan Bednařík aka Architekt
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/ZZkz9Q6B9BAJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Form assets and static file storage

[Dominic Rodger]

I recently came across a problem when using ManifestStaticFilesStorage on 
an app with form media, which the documentation doesn't seem to address. 
I'm posting here rather that on django-users, since I think we ought to at 
least document how to fix it, or preferably come up with a better way of 
solving it.

The app I was using is django-image-cropping, which specifies the media for 
a widget like this (see image_cropping/widgets.py#L60 

):

def _media(self):
js = [
"image_cropping/js/jquery.Jcrop.min.js",
"image_cropping/image_cropping.js",
]

css = {'all': ("image_cropping/css/jquery.Jcrop.min.css",
   "image_cropping/css/image_cropping.css",)}
return forms.Media(css=css, js=js)

media = property(_media)

When rendered to HTML, it generates a static path (i.e. STATIC_URL is 
prepended), but doesn't correctly generate paths to minified content, so 
you get 404s. django.contrib.admin has worked around this - by using the 
admin_static template tag (see 
django/contrib/admin/templatetags/admin_static.py#L10 
).
 
I fixed up django-image-cropping by porting that workaround to the app 
itself (see PR 
), but it 
feels like it might be worth documenting how people should be handling this 
in their apps. I'm thinking of something along the lines of making the code 
in admin_static.py less admin specific (so far as I can see, it doesn't 
actually have anything to do with django.contrib.admin) - perhaps exposing 
the functionality in django.utils, and then having the templatetag 
admin_static use that function.

If I've missed something, my apologies, but I couldn't find any tickets 
related to this. It seems like something others would have come across 
already, so again, apologies if there's already a ticket for this, or if 
I've gone about this in a braindead way.

If patches/tickets need writing, I'd be happy to get stuck in - just wanted 
some clarity that I'm not crazy first :)

Dom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/4683fd0f-9580-4d65-b303-b4a6667bdf37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Making assertNumQueries more useful by printing the list of queries executed on failure

[Dominic Rodger]

Currently, when assertNumQueries fails, the output is perhaps less helpful 
than it might be:

Traceback (most recent call last):
  File 
"/home/dom/.virtualenvs/kanisa/src/kanisa/kanisa/tests/views/public.py", 
line 31, in test_kanisa_root_view
[banner1.pk, banner2.pk, banner3.pk, banner5.pk, ])
  File 
"/home/dom/.virtualenvs/kanisa/src/kanisa/.tox/py27-1.5.X/local/lib/python2.7/site-packages/django/test/testcases.py",
 
line 195, in __exit__
executed, self.num
AssertionError: 5 queries executed, 99 expected


When an assertNumQueries check fails, the first thing I (and I'd guess 
everyone else too) want to know is what queries ran, so it'd be awesome if 
an assertNumQueries failure printed the list of queries. Charlie Denton has 
a blog post describing how he does this (
http://meshy.co.uk/posts/debugging-assertnumqueries-tests/), but I'd like 
to see this included in Django itself - since it seems generally helpful.

I'm very happy to work on this and provide a patch (and a ticket), I just 
wanted to solicit some feedback before I did too much work on it, in case 
I'm missing a reason why this hasn't already been done (I appreciate this 
can be done outside of Django, but I think its of sufficiently general 
utility to warrant being in core).

Dom

-- 
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/20327acd-1354-49dc-a5e0-16c4e7e6ee99%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Making assertNumQueries more useful by printing the list of queries executed on failure

[Dominic Rodger]

Filed as https://code.djangoproject.com/ticket/21462#ticket.

On Friday, November 15, 2013 8:28:09 PM UTC, Aymeric Augustin wrote:
>
> On 15 nov. 2013, at 18:38, gavi...@gmail.com  wrote:
>
> Every time I get a failure on one of these types of tests I go in and edit 
> the code to print out the queries that were executed. There's no way to 
> troubleshoot the problem without know the queries.
>
>
> I have also typed `from django.db import connection; 
> print(connection.queries)` countless times.
>
> We can debate whether assertNumQueries is a good practice — and with what 
> I know of Django’s source code, I don’t doubt it’s an issue for third-party 
> backends. Regardless I support making the failure message more useful.
>
> — 
> Aymeric.
>

-- 
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/e6c0c845-4bf5-4ff4-a1e8-dbe7d96cf83b%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.