On Tue, Nov 25, 2008 at 9:05 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> On Nov 25, 11:01 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
>> On Nov 25, 10:56 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
>> wrote:
>>
>>
>>
>> > On Tue, 2008-11-25 at 20:47 +0900, Russell Keith-Magee wrote:
>> > > On Tue, Nov 25, 2008 at 8:40 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
>>
>> > > > Hi,
>>
>> > > > I've got a view which uses a different template depending on an input
>> > > > parameter. For example:
>>
>> > > > def my_view(request, theme):
>> > > > ...
>> > > > return render_to_response('my_app/%s/page.html' %s theme, {...})
>>
>> > > > I would like to write some tests for this view, but I couldn't find
>> > > > any clean way to do so. So far, the only way I've found was to create
>> > > > a fake folder in the app's templates:
>>
>> > > > my_app/
>> > > > templates/
>> > > > my_app/
>> > > > test_blah/
>> > > > page.html
>> > > > models.py
>> > > > tests.py
>> > > > views.py
>>
>> > > > And then I can test the view by sending it the parameter 'test_blah'.
>> > > > It works fine, but it means I have to ship my app with that dirty
>> > > > "test_blah" folder.
>>
>> > > > Is there any other way to proceed?
>>
>> > > Check out django.contrib.auth.tests.views.py. The ChangePasswordTest
>> > > does some fancy footwork during the setUp and tearDown to install some
>> > > templates for testing purposes. You still need to ship the templates
>> > > as part of your project tarball, but they don't need to be in a
>> > > production-visible location - you can hide them away as part of the
>> > > testing infrastructure.
>>
>> > Another approach is to write a custom template loader that is used in
>> > your test settings file. There's nothing to say a template loader has to
>> > actually load a file. It has to return a template, given the name. You
>> > can do that however you like.
>>
>> > Regards,
>> > Malcolm
>>
>> Thanks also for this tip, Malcolm. Both approaches are quite elegant.
>
> I should add that the trickery used in ChangePasswordTest might be
> slightly better because it means the tests are self-contained, and so
> they don't depend on external parameters (e.g. the tests settings).
> The big advantage I see is that it makes the app more portable, at
> least as far as tests are concerned. Just tried it and it works like a
> charm!
If you want to get really fancy, you can actually combine the two
suggestions. Malcolm's suggestion is to introduce a 'test template
loader' which serves templates from memory (or, at least, from
somewhere other than a file). While Malcolm was suggesting that you do
this using a completely separate test settings file, you could also do
this using the setUp/tearDown trick to force the value of
TEMPLATE_LOADERS for the duration of the test case. This would remove
the dependency on an external settings file, while simultaneously
avoiding the need to have a directory full of test templates.
Whether it is worth the effort to set up this test infrastructure is
entirely up to you to decide, but I thought I'd point out the neat
trick just in case :-)
Yours,
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
