[Django] #11797: Test Client Response content form value parsing

[Django]

#11797: Test Client Response content form value parsing
-----------------------------------------------+----------------------------
Reporter: Rupe | Owner: nobody
Status: new | Milestone:
Component: Testing framework | Version: SVN
Keywords: test client content form post get | Stage: Unreviewed
Has_patch: 0 |
-----------------------------------------------+----------------------------
Added html parsing to the response object created in the test client to
extract the initial form field value to facilitate resubmission via post
and get.

Example:
{{{
response = self.client.get('/')
self.failUnlessEqual(response.status_code, 200, 'Failed to retrieve the
standard main page.')

# This retrieves the entire set of form values for the form associated
with the field (or form) name supplied
curVals = response.form_data('btnShow')
curVals['pessoaSelect'] = '2'

response = self.client.post('/', curVals)
self.failUnlessEqual(response.status_code, 200, 'Failed to retrieve the
list of Matriz records for the PessoaID 2 (1)')
}}}

--
Ticket URL: <http://code.djangoproject.com/ticket/11797>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#11797: Test Client Response content form value parsing

----------------------------------------+-----------------------------------

Reporter: Rupe | Owner: nobody
Status: new | Milestone:
Component: Testing framework | Version: SVN

Resolution: | Keywords: test client content form post get
Stage: Unreviewed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 1
Needs_better_patch: 0 |
----------------------------------------+-----------------------------------
Changes (by Rupe):

* needs_better_patch: => 0
* has_patch: 0 => 1
* needs_tests: => 1
* needs_docs: => 1

--
Ticket URL: <http://code.djangoproject.com/ticket/11797#comment:1>

[Django]

#11797: Test Client Response content form value parsing

----------------------------------------+-----------------------------------

Reporter: Rupe | Owner: nobody
Status: new | Milestone:
Component: Testing framework | Version: SVN

Resolution: | Keywords: test client content form post get
Stage: Unreviewed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 1
Needs_better_patch: 0 |
----------------------------------------+-----------------------------------

Comment (by Rupe):

I'm working the regression tests for this. Should I put the actual test
assertions in tests\regressiontests\test_client_regress\models.py? That
seems to be where all the rest of the tests have been placed.

--
Ticket URL: <http://code.djangoproject.com/ticket/11797#comment:2>

[Django]

#11797: Test Client Response content form value parsing

----------------------------------------+-----------------------------------

Reporter: Rupe | Owner: nobody
Status: new | Milestone:
Component: Testing framework | Version: SVN

Resolution: | Keywords: test client content form post get
Stage: Unreviewed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 1
Needs_better_patch: 0 |
----------------------------------------+-----------------------------------

Comment (by russellm):

`regressiontests/test_client_regress/models.py' is as reasonable place as
any to put tests for this. If it turns out that this feature requires a
_lot_ of tests, then it might be worth introducing a tests directory under
test_client_regress for organizational purposes, but otherwise just leave
it as is and append your tests to those already present.

--
Ticket URL: <http://code.djangoproject.com/ticket/11797#comment:3>

[Django]

#11797: Test Client Response content form value parsing

----------------------------------------+-----------------------------------

Reporter: Rupe | Owner: nobody
Status: new | Milestone:
Component: Testing framework | Version: SVN

Resolution: | Keywords: test client content form post get
Stage: Unreviewed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0

Needs_better_patch: 0 |
----------------------------------------+-----------------------------------
Changes (by Rupe):

* needs_docs: 1 => 0
* needs_tests: 1 => 0

Comment:

I'm not sure if it was appropriate to put the method documentation in the
middle of the attribute list, but other than that I think it's good to go.

--
Ticket URL: <http://code.djangoproject.com/ticket/11797#comment:4>

[Django]

#11797: Test Client Response content form value parsing

----------------------------------------+-----------------------------------
Reporter: Rupe | Owner: nobody
Status: new | Milestone: 1.2

Component: Testing framework | Version: SVN

Resolution: | Keywords: test client content form post get
Stage: Unreviewed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
----------------------------------------+-----------------------------------
Changes (by Rupe):

* milestone: => 1.2

--
Ticket URL: <http://code.djangoproject.com/ticket/11797#comment:5>

[Django]

#11797: Test Client Response content form value parsing

----------------------------------------+-----------------------------------
Reporter: Rupe | Owner: nobody
Status: new | Milestone: 1.2

Component: Testing framework | Version: SVN

Resolution: | Keywords: test client content form post get
Stage: Unreviewed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
----------------------------------------+-----------------------------------

Comment (by rpbarlow):

As per some discussion, it seems to be agreed that we shouldn't try to
duplicate the functionality of projects like Twill. This patch is parsing
HTML to get the form data. A more desirable solution is to use the request
context to get the form. The down side to that approach is that not all
form elements are always available in the context.

--
Ticket URL: <http://code.djangoproject.com/ticket/11797#comment:6>

[Django]

#11797: Test Client Response content form value parsing

----------------------------------------+-----------------------------------
Reporter: Rupe | Owner: nobody
Status: new | Milestone: 1.2

Component: Testing framework | Version: SVN

Resolution: | Keywords: test client content form post get
Stage: Unreviewed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
----------------------------------------+-----------------------------------
Comment (by rpbarlow):

Here is a discussion about this: http://groups.google.com/group/django-
developers/browse_thread/thread/cd9695f8b98e8406/?pli=1

--
Ticket URL: <http://code.djangoproject.com/ticket/11797#comment:7>

[Django]

#11797: Test Client Response content form value parsing

----------------------------------------+-----------------------------------
Reporter: Rupe | Owner: nobody
Status: new | Milestone: 1.2

Component: Testing framework | Version: SVN

Resolution: | Keywords: test client content form post get
Stage: Unreviewed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
----------------------------------------+-----------------------------------

Changes (by rpbarlow):

* cc: rpbarlow (added)

--
Ticket URL: <http://code.djangoproject.com/ticket/11797#comment:8>

[Django]

#11797: Test Client Response content form value parsing

---------------------------------------------+------------------------------
Reporter: Rupe | Owner: nobody
Status: new | Milestone: 1.2

Component: Testing framework | Version: SVN

Resolution: | Keywords: test client content form post get
Stage: Design decision needed | Has_patch: 1

Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |

---------------------------------------------+------------------------------
Comment (by Rupe):

Replying to [comment:6 rpbarlow]:

> As per some discussion, it seems to be agreed that we shouldn't try to
duplicate the functionality of projects like Twill. This patch is parsing
HTML to get the form data. A more desirable solution is to use the request
context to get the form. The down side to that approach is that not all
form elements are always available in the context.

I understand the concern about overlap though the context side doesn't
seem to be really viable. In addition to not always having all of the
elements as you point out (say you have a hard coded hidden field), you
can also have conditional templates. You would then have to duplicate the
template conditions in your testing logic and thus not test the template
logic.

--
Ticket URL: <http://code.djangoproject.com/ticket/11797#comment:10>

[Django]

#11797: Test Client Response content form value parsing

---------------------------------------------+------------------------------
Reporter: Rupe | Owner: nobody
Status: new | Milestone: 1.2

Component: Testing framework | Version: SVN

Resolution: | Keywords: test client content form post get
Stage: Design decision needed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------+------------------------------
Comment (by Rupe):

An other thought ... One of the other main reasons for creating this logic
is to cleanup the testing logic. If you open
\test\regressiontests\admin_views\tests.py and search for 'data = {', you
will find 19 different locations where post data is constructed manually.
It would make for much more readable code if we were retrieving a
page/form, modifying the from data, and then re-submitting it.

Also, it would make for better real world tests, because otherwise we have
no idea if the forms are being created properly (as I mentioned
previously).

Are there currently Twill tests for Django?

--
Ticket URL: <http://code.djangoproject.com/ticket/11797#comment:11>

[Django]

#11797: Test Client Response content form value parsing

---------------------------------------------+------------------------------

Reporter: Rupe | Owner: nobody
Status: new | Milestone:
Component: Testing framework | Version:

Resolution: | Keywords: test client content form post get
Stage: Design decision needed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------+------------------------------

Changes (by russellm):

* version: SVN =>
* milestone: 1.2 =>

--
Ticket URL: <http://code.djangoproject.com/ticket/11797#comment:12>

[Django]

#11797: Test Client Response content form value parsing

---------------------------------------------+------------------------------
Reporter: Rupe | Owner: Rupe
Status: assigned | Milestone: 1.3

Component: Testing framework | Version: SVN

Resolution: | Keywords: test client content form post get
Stage: Design decision needed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------+------------------------------

Changes (by Rupe):

* owner: nobody => Rupe
* status: new => assigned
* version: => SVN
* milestone: => 1.3

Comment:

I understand that this is way to late for 1.2 but I thought I would bring
it up to date anyway and I had an improvement I wanted to make anyway

--
Ticket URL: <http://code.djangoproject.com/ticket/11797#comment:13>

Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups "Django updates" group.
To post to this group, send email to django-...@googlegroups.com.
To unsubscribe from this group, send email to django-update...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-updates?hl=en.

[Django]

#11797: Test Client Response content form value parsing

---------------------------------------------+------------------------------
Reporter: Rupe | Owner: Rupe
Status: assigned | Milestone: 1.3

Component: Testing framework | Version: SVN

Resolution: | Keywords: test client content form post get
Stage: Design decision needed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------+------------------------------

Changes (by kmike):

* cc: kmike (added)

Comment:

This is indeed an unnecessary duplication of work that have been done by
twill and [http://pythonpaste.org/webtest/ WebTest].

Twill can be integrated using [http://pypi.python.org/pypi/django-test-
utils django-test-utils], tddspry and django-sane-testing, webtest can be
integrated using [http://pypi.python.org/pypi/django-webtest/ django-
webtest].

With django-webtest you don't lose native django test client features like
.template, .context, assertTemplateUsed, assertFormError. And it is able
to do much more than just filling initial values for forms. So you can
just use django-webtest instead of native django test client for your apps
and get almost all django's test client benefits plus an easy and powerful
API.

On the other hand, django's test suite can certainly benefit from such
feature.

But bundling immature self-baked (maybe high-quality though)
implementation looks like NIH. I don't think that bundling mature
implementation make sense either. So I think the best way is to leave
things as-is. It is even documented that something like twill should be
used instead of native test client for integrational-style tests.

--
Ticket URL: <http://code.djangoproject.com/ticket/11797#comment:14>

[Django]

#11797: Test Client Response content form value parsing

---------------------------------------------+------------------------------
Reporter: Rupe | Owner: Rupe
Status: assigned | Milestone: 1.3

Component: Testing framework | Version: SVN

Resolution: | Keywords: test client content form post get
Stage: Design decision needed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------+------------------------------

Comment (by Rupe):

@kmike Why doesn't it make sense to bundle a mature implementation? I
think that we could improve the level of testing by reducing the
complexity of the test scripts with this or something like django-webtest.

--
Ticket URL: <http://code.djangoproject.com/ticket/11797#comment:15>

[Django]

#11797: Test Client Response content form value parsing

---------------------------------------------+------------------------------
Reporter: Rupe | Owner: Rupe
Status: assigned | Milestone: 1.3

Component: Testing framework | Version: SVN

Resolution: | Keywords: test client content form post get
Stage: Design decision needed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------+------------------------------

Comment (by kmike):

There is no decent solution that fits everyone.

Mature usually means a bunch of code.

Last twill release is in 2007, twill's unicode support is just bad and
nobody is maintaining twill now. Bundling twill means that fixing twill
bugs will become a responsibility of core team while there are already >
1000 open tickets (with patches! not to mention ones without patches) in
django bug tracker competing for core team's time.

django-webtest is immature integration layer and is in active development
itself. It depends on mature WebTest. WebTest is actively developed by Ian
Bicking and bundling it in django will slow down this process (or Django
will always have outdated WebTest version). WebTest also depends on WebOb
so if we want to bundle WebTest then we will have to bundle WebOb (which
is an another separately developed package). WebOb is an alternative to
django's Request object so if we bundle django-webtest then we suddenly
have 2 Request object implementations in django trunk. That's crazy :)

All of this is not a problem if we don't bundle anything. From app
developer point of view the install process for all of these packages is
easy and straightforward so if anyone want to use nicer API for test he
can do it easily. On other hand, bundling twill or WebTest will require
massive test refactoring and will lead to maintain burden. I think it is
just not practical in current situation.

--
Ticket URL: <http://code.djangoproject.com/ticket/11797#comment:16>

[Django]

#11797: Test Client Response content form value parsing

---------------------------------------------+------------------------------
Reporter: Rupe | Owner: Rupe
Status: assigned | Milestone: 1.3

Component: Testing framework | Version: SVN

Resolution: | Keywords: test client content form post get
Stage: Design decision needed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------+------------------------------

Comment (by Rupe):

Ok, with that said, I agree the other options are not a good fit for the
trunk.

There is still the reason why I created this patch; to clean up the
existing test code and hopefully create more robust testing via the
simplicity it affords. Do you believe that is not reason enough to include
this patch?

--
Ticket URL: <http://code.djangoproject.com/ticket/11797#comment:17>

[Django]

#11797: Test Client Response content form value parsing

---------------------------------------------+------------------------------
Reporter: Rupe | Owner: Rupe
Status: assigned | Milestone: 1.3

Component: Testing framework | Version: SVN

Resolution: | Keywords: test client content form post get
Stage: Design decision needed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------+------------------------------

Comment (by kmike):

I like your intentions very much because this is really a better way to
write tests than django's current method.

But I think that in practice efforts to support this feature can outweighs
benefits it provide.

For example, your patch uses HTMLParser. HTMLParser is known for it's bad
parsing of normal real-world (but maybe invalid) HTML. This is one of the
reasons there are a lot of other parsing libraries (lxml, BeautifulSoup,
html5lib, ...). So there will be tickets complaining about test client
html parsing. So there will be patches and HTMLParser workarounds - and
this can eventually lead to django's own half-baked html parsing library.

The benefit over using django-test-utils or django-webtest is only an
easier testing of django itself.

But converting django test suite to use new method also have some
downsides: html parsing takes time and test suite will run longer.
Existing suite is huge and converting it is a non-trivial work.

I'm not a core developer and they possibly don't share my point of view so
take all these as a personal opinion. This is all about balance and
balance is a subjective matter.

--
Ticket URL: <http://code.djangoproject.com/ticket/11797#comment:18>

[Django]

#11797: Test Client Response content form value parsing

-------------------------------------+-------------------------------------
Reporter: Rupe | Owner: Rupe
Type: New | Status: assigned
feature | Component: Testing framework
Milestone: 1.3 | Severity: Normal

Version: SVN | Keywords: test client content

Resolution: | form post get
Triage Stage: Design | Has patch: 1
decision needed | Needs tests: 0
Needs documentation: 0 |
Patch needs improvement: 0 |
-------------------------------------+-------------------------------------
Changes (by baumer1122):

* type: => New feature
* severity: => Normal

--
Ticket URL: <http://code.djangoproject.com/ticket/11797#comment:19>