Re: Test runner with search

2012-06-14 Thread Carl Meyer 


On 06/14/2012 07:25 AM, Jannis Leidel wrote:
> On 14.06.2012, at 12:35, Chris Wilson wrote:
>> Hi all,
>> 
>> I've made some improvements (in my view) to the
>> DjangoTestSuiteRunner. I got tired of having to remember my test
>> class names and of typing so much:
>> 
>> ./manage.py test binder.BinderTest.test_can_create_users
>> 
>> This new version searches for tests with the given name in all 
>> INSTALLED_APPS, so you can just type this:
>> 
>> ./manage.py test test_can_create_users
>> 
>> You can find the source code here:
>> 
>> https://github.com/aptivate/intranet-binder/blob/master/testing.py
>> 
>> Is this something that might be interesting to add to Django core?
> 
> 
> Yes! In fact there is a ticket for it already:
> https://code.djangoproject.com/ticket/17365
> 
> I've also released a almost similar tool called
> django-discover-runner based on Carl's work:
> http://pypi.python.org/pypi/django-discover-runner

It looks to me like Chris' added feature is actually kind of orthogonal
to #17365. #17365 is about lifting the "tests must be in tests.py of an
installed app" restriction in favor of unittest2 discovery. Chris' patch
allows searching for a test by name alone rather than full
app.TestCase.name.

Both seem useful enough, and could be combined. It pains me a bit to add
more specialized features to Django's test runner, rather than upstream
in one of the commonly-used Python test runners (such as unittest2), as
I'd rather move in the direction of less custom Django test-runner code
rather than more. But I guess that has to be balanced against the
convenience value of the feature.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
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.

Re: Test runner with search

2012-06-14 Thread Daniel Moisset 
On Thu, Jun 14, 2012 at 7:35 AM, Chris Wilson  wrote:
> Hi all,
>
> I've made some improvements (in my view) to the DjangoTestSuiteRunner. I
> got tired of having to remember my test class names and of typing so much:
>
>  ./manage.py test binder.BinderTest.test_can_create_users
>

In this same line, there's also
http://pypi.python.org/pypi/django-test-autocomplete ; although that's
more bash-oriented

Regards,
 D.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
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.

Re: Test runner with search

2012-06-14 Thread Chris Wilson 
Hi Andrew,

On Thu, 14 Jun 2012, Andrew Godwin wrote:

> +1 from me as well - the test runner you linked to looks reasonably 
> sane, only a few small things that I'm questioning (like why types is 
> imported inside the for loop).

I prefer to keep the imports as close to the code that uses them as 
possible, to make it easier to move code around and reduce "action at a 
distance". That's just my personal preference and of course if it's merged 
into Django then it can use the Django style.

Cheers, Chris.
-- 
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cambridge City FC, Milton Road, Cambridge CB4 1UY

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
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.

Re: Test runner with search

2012-06-14 Thread Jannis Leidel 
On 14.06.2012, at 12:35, Chris Wilson wrote:

> Hi all,
> 
> I've made some improvements (in my view) to the DjangoTestSuiteRunner. I 
> got tired of having to remember my test class names and of typing so much:
> 
>  ./manage.py test binder.BinderTest.test_can_create_users
> 
> This new version searches for tests with the given name in all 
> INSTALLED_APPS, so you can just type this:
> 
>  ./manage.py test test_can_create_users
> 
> You can find the source code here:
> 
>  https://github.com/aptivate/intranet-binder/blob/master/testing.py
> 
> Is this something that might be interesting to add to Django core?


Yes! In fact there is a ticket for it already: 
https://code.djangoproject.com/ticket/17365

I've also released a almost similar tool called django-discover-runner based on 
Carl's work: http://pypi.python.org/pypi/django-discover-runner

Jannis

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
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.

Re: Test runner with search

2012-06-14 Thread Andrew Godwin 
On 14/06/12 11:51, Anssi Kääriäinen wrote:
> On 14 kesä, 13:35, Chris Wilson  wrote:
>> I've made some improvements (in my view) to the DjangoTestSuiteRunner. I
>> got tired of having to remember my test class names and of typing so much:
>>
>>   ./manage.py test binder.BinderTest.test_can_create_users
>>
>> This new version searches for tests with the given name in all
>> INSTALLED_APPS, so you can just type this:
>>
>>   ./manage.py test test_can_create_users
> 
> A big +1 to easier running of single tests. I haven't checked the
> implementation / API details at all. But I do know I would have
> immediate use for this feature in running Django's tests.

+1 from me as well - the test runner you linked to looks reasonably
sane, only a few small things that I'm questioning (like why types is
imported inside the for loop).

> Another feature which I would find useful would be "--log-failed-
> cases=somefile". Then you could re-run the failed tests using:
> 
> ./manage.py test < somefile
> 
> I would find this very useful in fixing regressions - run the full
> test suite - fix regressions - try to run the failed cases - fix more
> - run the failed cases again - when done rerun full test suite.
> 
> Anybody else for this feature?

Interesting idea - I can see that being useful, too. Presumably we're
just talking an output with one test function reference per line?

Not sure about having to read from stdin - I can see that potentially
interfering with things like pdb.set_trace() - but there's always the
option of adding a command-line flag too.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
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.

Re: Test runner with search

2012-06-14 Thread Anssi Kääriäinen 
On 14 kesä, 13:35, Chris Wilson  wrote:
> I've made some improvements (in my view) to the DjangoTestSuiteRunner. I
> got tired of having to remember my test class names and of typing so much:
>
>   ./manage.py test binder.BinderTest.test_can_create_users
>
> This new version searches for tests with the given name in all
> INSTALLED_APPS, so you can just type this:
>
>   ./manage.py test test_can_create_users

A big +1 to easier running of single tests. I haven't checked the
implementation / API details at all. But I do know I would have
immediate use for this feature in running Django's tests.



Another feature which I would find useful would be "--log-failed-
cases=somefile". Then you could re-run the failed tests using:

./manage.py test < somefile

I would find this very useful in fixing regressions - run the full
test suite - fix regressions - try to run the failed cases - fix more
- run the failed cases again - when done rerun full test suite.

Anybody else for this feature?

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
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.

Test runner with search

2012-06-14 Thread Chris Wilson 
Hi all,

I've made some improvements (in my view) to the DjangoTestSuiteRunner. I 
got tired of having to remember my test class names and of typing so much:

  ./manage.py test binder.BinderTest.test_can_create_users

This new version searches for tests with the given name in all 
INSTALLED_APPS, so you can just type this:

  ./manage.py test test_can_create_users

You can find the source code here:

  https://github.com/aptivate/intranet-binder/blob/master/testing.py

Is this something that might be interesting to add to Django core?

Cheers, Chris.
-- 
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cambridge City FC, Milton Road, Cambridge CB4 1UY

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
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.

Re: QuerySet refactoring

2012-06-14 Thread Anssi Kääriäinen 
On 14 kesä, 10:59, Aymeric Augustin
 wrote:
> Hello Anssi,
>
> I'm familiar with the topic since I tried to review some of your
> refactoring patches (before you gained the ability to commit them
> yourself).
>
> I'm convinced that this refactoring is useful, because it is likely to
> fix some bugs, especially in features that were added to the ORM long
> after its original design, and it will make ongoing maintenance
> easier.
>
> It's also very difficult to review and I'm afraid I may not be able to
> help a lot, besides sanity-checking patches. Anyway, ask loudly for
> reviews when you have patches ready, and I'll try to join the effort.

Thanks for all for the offers for reviews.

I think I will go forward with the following plan:
  - For small issues I will create a ticket + pull request and
announce that I am going to commit the request. I will wait for couple
of days and commit if no objections or requests for more time are
raised.
  - For medium issues I will ask for a review and wait for one.
  - For bigger issues (db schemas, deepcopy() vs. clone()) there need
to be some form of consensus that the approach is in fact correct.

Lets see how the above works. If it doesn't, then lets figure out some
other way. A branch for "orm-next" could work also...

I will post a short request here on django-developers, and then detail
the request in the ticket.

For now the big issue needing review is the django.utils.tree/add_q
refactor. https://code.djangoproject.com/ticket/17000#comment:7 and
https://github.com/akaariai/django/commits/refactor_utils_tree

I would like to get the qs deepcopy/clone() thingy moved forward or
closed as wontfix. Luckily this is a well separated issue from rest of
queryset refactor, so there is no hurry for this one:
https://code.djangoproject.com/ticket/16759#comment:33

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
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.

Re: ModelForms and the Rails input handling vulnerability

2012-06-14 Thread Anssi Kääriäinen 
On 14 kesä, 09:03, Alex Ogier  wrote:
> Right, the Django situation is already considerably more secure than the
> Rails status quo. They have a whitelist or blacklist of attributes that
> they have declared "accessible", independent of forms, making it easy to
> misunderstand  that any form can update any accessible attribute regardless
> of the input fields the developer has included.
>
> Our forms only validate the fields they explicitly or implicitly include.
> The only way to get a security hole is to have a mismatch between the
> fields in your python form and the input fields in your HTML. Since all our
> forms are explicit, it is feasible to catch that scenario and throw an
> error, which I think we should do.

There is an additional important distinction between Django and Rails:
In Django, when a field is not part of the POST, but it is part of the
ModelForm, it will be validated and saved on basis of the POST value
(that is, set to None as it is missing), In Rails, it will keep its
original value from the database.

Thus, in Django it is easier to spot that all of the fields in the
ModelForm are editable due to "this field is required" errors on
form.is_valid(), or the field getting set to NULL on form.save().
Also, users are likely to restrict the fields by hand even if they
render only a part of them, as otherwise the fields will be
overwritten to NULL on save.

It would be useful to warn about missing POST keys. In addition to the
security issue, missing HTML form elements will likely result in
"overwrite to NULL" issues. We can not warn about checkboxes, as those
are not always part of the POST even if they are in the HTML form, but
for other fields we should be able to do the warnings. There are use
cases where the warnings are just noise, so add some way to suppress
the.

I made a _very_ quick branch made on the above idea: on
ModelForm.is_valid() the data and self.fields are checked for possible
missing pieces of data. I don't know if this idea is practical due to
differences in browsers. The branch is available here:
https://github.com/akaariai/django/compare/warn_missing_keys

I don't see our ModelForms situation as comparable to the Rails
situation. The scope for security issues is much smaller for us than
for Rails.

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
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.

Re: QuerySet refactoring

2012-06-14 Thread Aymeric Augustin 
Hello Anssi,

I'm familiar with the topic since I tried to review some of your
refactoring patches (before you gained the ability to commit them
yourself).

I'm convinced that this refactoring is useful, because it is likely to
fix some bugs, especially in features that were added to the ORM long
after its original design, and it will make ongoing maintenance
easier.

It's also very difficult to review and I'm afraid I may not be able to
help a lot, besides sanity-checking patches. Anyway, ask loudly for
reviews when you have patches ready, and I'll try to join the effort.

Best regards,

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
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.

Re: ModelForms and the Rails input handling vulnerability

2012-06-14 Thread Alex Ogier 
On Jun 14, 2012 1:54 AM, "Torsten Bronger" 
wrote:
>
> But can one guarantee that fields rendered in the browser are also
> sent back in the POST request?  Even worse, how about non-browser
> requests?
>

Ugh. I forget that checkboxes don't return anything else when they are
unchecked. Kind of throws a wrench in my plan.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
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.

Re: ModelForms and the Rails input handling vulnerability

2012-06-14 Thread Alex Ogier 
On Jun 14, 2012 12:48 AM, "Anssi Kääriäinen" 
wrote:
>
> This seems to be different from what Rails do: they have
> update_attributes which updates all model attributes present in the
> request, but lefts all others untouched. So, in Rails if you render
> only part of the fields in update view, then you will not get the non-
> included fields overwritten to NULL, which conveniently hides the
> problem that the fields are in fact editable through the request.
>
> To me it seems there is no similar attack vector against Django's
> implementation as there were against Rails.
>

Right, the Django situation is already considerably more secure than the
Rails status quo. They have a whitelist or blacklist of attributes that
they have declared "accessible", independent of forms, making it easy to
misunderstand  that any form can update any accessible attribute regardless
of the input fields the developer has included.

Our forms only validate the fields they explicitly or implicitly include.
The only way to get a security hole is to have a mismatch between the
fields in your python form and the input fields in your HTML. Since all our
forms are explicit, it is feasible to catch that scenario and throw an
error, which I think we should do.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
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.