> I think you could create an urls.py file for your tests and attach
> your views there. Then use the test client to direct requests to those
> test URLs and assert that the response is what you expect.
I didn't know that could work.
I think I'll also need to create views that extend these views that I want to
test.
Since they need actual implementation, I think, such as template_name and model
etc ..
How would the test client then now where to look for these views, since there
will be some reversing involved I think.
self.client.get(reverse("ajax_form_view"))
I don't see how the client will find my urls.py file and without the broader,
actual django application as context ?
>
> Now, this is probably not going to be practical to test your jQuery
> components, but you might want to ask on a JS-focused list regarding
> unittesting JS for this purpose.
>
> Thomas
>
> 2012/9/12 Jonas Geiregat <jo...@geiregat.org>:
>>
>> I can now show you what I really would like to write tests for.
>>
>> https://github.com/jonasgeiregat/django-ajax-forms
>>
>> The code I would like to test is in ajax_forms/views.py mainly the
>> AjaxFormView and the AjaxModelFormView.
>>
>> Any help is appreciated!
>>
>>
>> Is it a view mix in?
>>
>> The package actually already changed from containing a view mix in to actual
>> views that should be subclassed by the users using the package.
>>
>> It's a bit difficult to tell you much without more information.
>>
>> For example, a view derived from FormView. Like I said the user should
>> subclass this view again as you would normally do with CBV.
>>
>> Currently the package is just a package/directory with views.py, models.py,
>> urls.py and of course __init__.py to make it a module.
>>
>> It's hard to test views without having an actual django project to test it
>> again, I think. Correct me if I'm wrong here.
>> So I created an example django project that is using this package in the
>> directory below the package, thus the directory containing the README,
>> setup.py etc .. files.
>>
>> The example app will hold a tests.py file which will contain my tests which
>> will be testing the actual functionality of my views.
>>
>> Basically I'm asking do I need an actual django project to test just a
>> views.py file or can I just write some tests without a containing django
>> project to test a views.py file.
>> And if so, I'm kinda lost on how you would start on such a task.
>>
>> A few you things that you may find useful or not for testing :
>>
>> . Test cases can override settings such as the urlconf
>> . There's a test client to test views
>> . Class based views can sometimes be tested without any of the former by
>> just testing the methods in them
>> . You can always use mocking library
>> . Tests are basically just python code with a lot of asserts, you can
>> always add viewed in them
>> . You can use fixtures for test data if you see fit
>>
>> Hope this helps!
>>
>> Thomas
>>
>> On Sep 10, 2012 5:23 PM, "Jonas Geiregat" <jo...@geiregat.org> wrote:
>>>
>>> Hello,
>>>
>>> I've created a simple reusable django package. This package basically
>>> consists out of a views.py file, with some helper functions.
>>>
>>> I want to write some tests for what's in this file. This file contains a
>>> mixin , so I probably can't test it directly.
>>>
>>> What's the best way to test a django package ?
>>>
>>> Do I need to include some kind of example project that, uses my mixin and
>>> has tests files just as one would test a normal django application ?
>>>
>>> I've tried googling but, there's little about this. Most of the things
>>> I've found where related to testing actual django applications.
>>>
>>> Any help is appreciated.
>>>
>>> Jonas
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django users" group.
>>> To post to this group, send email to django-users@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> django-users+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/django-users?hl=en.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To post to this group, send email to django-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-users?hl=en.
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To post to this group, send email to django-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-users?hl=en.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To post to this group, send email to django-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-users?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
