On Tue, Jun 22, 2010 at 6:48 AM, Gustavo Narea <m...@gustavonarea.net> wrote: > Hello. > > On Jun 14, 1:39 pm, Russell Keith-Magee <russ...@keith-magee.com> > wrote: >> Ok - at this point, I'm broadly happy with your proposals (subject to >> the caveats I've given along the way). The next step is to show us >> actual code. This won't get applied to trunk as a single monolithic >> "fix WSGI" patch - it needs to be (at least) 4 patches, one for each >> feature that is being added, and each patch will need to be tested >> (and if appropriate, documented). Each of these features should also >> be logged as a ticket (if they aren't already). >> >> If you're looking to maximize the likelihood that this will land in >> trunk, the best approach will be to concentrate on one of the four >> issues (preferably starting with a small one), and see it through to >> completion; then move onto the next issue, and so on. > > > I've started to work on this, but I'm kind of stuck because I don't > know where to put the tests. > > The first patch (wsgiorg.routing_args implementation; #12075) would > involve adding a couple of lines to > django.core.handlers.base:BaseHandler.get_response() (to put the > arguments in the request) and also adding a couple of methods in > HttpRequest to access pythonically the so-called positional and named > arguments in the request, so we'd need tests for these two components > (i.e., the request and the handler). > > I found an existing test suite for request objects (regressiontests/ > requests/tests.py), but it has only ~6 doctests and I'm not sure if > you really want me to introduce these new tests as doctests, given > that the rest of the test suite seems to use regular unit tests. > > As for tests for the handlers, I wasn't able to find any; / > regressiontests/servers/tests.py is the closest thing I found, but I'm > not sure that handler-related tests fit there. If I had to add a new > test suite, I thought it would be best to create it for WSGI-related > tests in tests/regressiontests/wsgi/ because it could be reused by my > future patches.
You're correct that the handlers aren't extensively tested at the moment (except indirectly through the test client). If one of the upshots of your work is to improve this, then I'd call that a big win. Excluding indirect testing effects, the tests for the WSGI interface are in three places: * regressiontests/servers * regressiontests/builtin_server * regressiontests/request None of these are especially rigorous tests; in fact, the first two should probably be merged into a single directory testing the operation of the builtin server. So - I'd say your suggestion of a new test directory is the right approach. I'd be inclined to call that directory "regressiontests/handlers", and put WSGI tests as a submodule of that directory (after all, WSGI is just one of the server interfaces we support). Regarding doctests - one of the current GSoC projects is trying to replace all the doctests with unittests. If you're adding new tests, stick to unittests. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
