Re: template list empty in with django test client

[Juan Pablo Romero Méndez]

My fault. I was testing from the console. Within an actual test the
request does have the templates.

   Juan Pablo

El día 28 de agosto de 2011 17:50, Juan Pablo Romero Méndez
<jpablo.rom...@gmail.com> escribió:
> Hello,
>
> I'm using the django test client, like this:
>
>>>> c = Client()
>>>> r = c.get("/content/new/")
>>>> r.status_code
> 200
>>>> r.templates
> []
>
> Is this normal?
>
> Regards,
>
>  Juan Pablo
>

-- 
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.

template list empty in with django test client

[Juan Pablo Romero Méndez]

Hello,

I'm using the django test client, like this:

>>> c = Client()
>>> r = c.get("/content/new/")
>>> r.status_code
200
>>> r.templates
[]

Is this normal?

Regards,

  Juan Pablo

-- 
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.

Re: How to add CSRF to context when using test client???

[Matteius]

Thanks for both suggestions, I recently tried this approach and
reached success when I ran my tests.  So I think this is the correct
approach and I'll include this CSRF style testing with my test suite
now.

-Matteius

On Jul 7, 6:02 am, Craig Blaszczyk <masterja...@gmail.com> wrote:
> csrf_token is a proxy object not a string.
>
> Try doing:
> csrf_token = '%s' % response.context['csrf_token']

-- 
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.

Re: Django Test Corrupted Test Data

[Malcolm Box]

According to the SO post, you're seeing TestObject.objects.all().count()
return two different values on successive calls.

That is basically impossible unless there's something else getting in there
and doing stuff to your db.

Alternatively, does your subclass of TestCase correctly call
super(MyTestCase, self).setUp() and other superclass methods to get the DB
setup right?

Malcolm

On 19 August 2011 22:05, patjenk <patj...@gmail.com> wrote:

> As I understand it, the database should be reset between each test. To
> me this means that unless the variable being examined is an attribute
> of self, the tests shouldn't affect each other.
>
> Could it be possible that there is a sqllite subtly that delays the
> reset of the table count and it affects the outcome of the test in
> this instance?
>
> On Aug 19, 3:43 pm, bik...@gmail.com wrote:
> > Could it be that the tests affect each other (when ran in a series)?
> >
> > Sent from my BlackBerry® from Vodafone
> >
> > -Original Message-
> > From: dm03514 <dm03...@gmail.com>
> >
> > Sender: django-users@googlegroups.com
> > Date: Fri, 19 Aug 2011 12:13:24
> > To: Django users<django-users@googlegroups.com>
> > Reply-To: django-users@googlegroups.com
> > Subject: Django Test Corrupted Test Data
> >
> > I have a test class that subclasses django.test.TestCase which has
> > about 5 different tests in it. When I run my full test suite (using
> > nose, and specifying sqlite as backend) there are a series of
> > failures. When I go to debug the tests, running them individually,
> > they pass fine.
> >
> > http://stackoverflow.com/questions/7126172/django-testrunner-incorrec...
> >
> > --
> > 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 athttp://
> 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.
>
>


-- 
Malcolm Box
malcolm@gmail.com

-- 
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.

Re: Django Test Corrupted Test Data

[patjenk]

As I understand it, the database should be reset between each test. To
me this means that unless the variable being examined is an attribute
of self, the tests shouldn't affect each other.

Could it be possible that there is a sqllite subtly that delays the
reset of the table count and it affects the outcome of the test in
this instance?

On Aug 19, 3:43 pm, bik...@gmail.com wrote:
> Could it be that the tests affect each other (when ran in a series)?
>
> Sent from my BlackBerry® from Vodafone
>
> -Original Message-
> From: dm03514 <dm03...@gmail.com>
>
> Sender: django-users@googlegroups.com
> Date: Fri, 19 Aug 2011 12:13:24
> To: Django users<django-users@googlegroups.com>
> Reply-To: django-users@googlegroups.com
> Subject: Django Test Corrupted Test Data
>
> I have a test class that subclasses django.test.TestCase which has
> about 5 different tests in it. When I run my full test suite (using
> nose, and specifying sqlite as backend) there are a series of
> failures. When I go to debug the tests, running them individually,
> they pass fine.
>
> http://stackoverflow.com/questions/7126172/django-testrunner-incorrec...
>
> --
> 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 
> athttp://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.

Re: Django Test Corrupted Test Data

[bikkit]

Could it be that the tests affect each other (when ran in a series)?

Sent from my BlackBerry® from Vodafone

-Original Message-
From: dm03514 <dm03...@gmail.com>
Sender: django-users@googlegroups.com
Date: Fri, 19 Aug 2011 12:13:24 
To: Django users<django-users@googlegroups.com>
Reply-To: django-users@googlegroups.com
Subject: Django Test Corrupted Test Data

I have a test class that subclasses django.test.TestCase which has
about 5 different tests in it. When I run my full test suite (using
nose, and specifying sqlite as backend) there are a series of
failures. When I go to debug the tests, running them individually,
they pass fine.

http://stackoverflow.com/questions/7126172/django-testrunner-incorrect-query-counts-corrupted-data-general-mayhem

-- 
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.

Django Test Corrupted Test Data

[dm03514]

I have a test class that subclasses django.test.TestCase which has
about 5 different tests in it. When I run my full test suite (using
nose, and specifying sqlite as backend) there are a series of
failures. When I go to debug the tests, running them individually,
they pass fine.

http://stackoverflow.com/questions/7126172/django-testrunner-incorrect-query-counts-corrupted-data-general-mayhem

-- 
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.

Re: How to test form values in a template? (simplified)

[Shawn Milochik]

The validation is easy. Override the form's clean() method to do any 
validation which needs to check the value of more than one field. For 
example, if you want a text box to be required sometimes, define it as 
not required in the form, then check the boolean in clean() and raise a 
forms.ValidationError if appropriate.


If you want to change which widget is being used and where it's 
displayed based on the checkbox then you'd have to use AJAX to make that 
work "live" anyway. Or maybe have two form fields, one of each type, and 
dynamically hide one and show the other when the checkbox is changed. 
You could also use your form's clean() override to assign the correct 
value to your form field.


Example:
Say you have a field named named 'reason,' and you want to make it 
a select box with hard-coded choices if a boolean for is True, but a 
free-form text field if it's False.


If you have fields named reason_select and reason_text, you could 
use JavaScript to select the appropriate one to show based on the checkbox.


Then, in form.clean(), you use the value of the checkbox to 
determine whether to fill self.cleaned_data['reason'] with the value 
from self.cleaned_data['reason_select'] or self.cleaned_data['reason_text'].


I hope this helps. I think we're zeroing in on your solution.

--
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.

Re: How to test form values in a template? (simplified)

[Joshua Russo]

It's more that I want to have different ways of displaying the same form 
field. I want the text field to be on the same line as the checkbox when 
it's an input field and below it when it's displayed as a textarea. There's 
also the point of changing the required setting of the same field based on 
if the checkbox is selected or not. 

I guess what I'm trying to get at is, how should I access these values to 
determine the display and validation. If I don't use my method I will have 
to test for both the boolean value and the string value 'True' instead. 
That's what I'm trying to avoid.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/HDa2SptnYuEJ.
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.

How to test form values in a template? (simplified)

[Joshua Russo]

I realize that I went from too little information, to too much information 
in the previous post, so this is an attempt to find a middle ground.

What I'm building is the ability to have a list of checkable options, and 
depending on the setup for a give option it may have a text field to enter 
additional information. This text field can be either displayed as a single 
line text input or a multi-line textarea. 

My problem is that I want to have these different setup values available to 
control the validation and display of the form, but there doesn't seem a 
consistent way to test the values. When the form is POSTed back and isn't 
valid, the value out of the BoundField's value() metod for BooleanFields is 
a string, where it's a actual boolean on the initial creation of the page. I 
understand why this is, it's pulling from the POST data instead of the 
initial data. 

The way I over came this was to add a to_python() method to the BoundField 
class in django/forms/forms.py:

def to_python(self):
return self.field.to_python(self.value())

Below is what I'm doing. I'm using the new to_python() method are in the 
__init__ of the form, the save logic of the view, and the template at the 
end. I left out the CreateItemsSection() function that builds of the 
listItems dict because its convoluted. The listItems structure is in a form 
that's easily looped through in the template and the function creates (on 
the initial load) or inserts (on POST back) the forms of the formset. If it 
would be helpful I can post it but I think there should be enough 
information here.

Is there a better way to accomplish what I'm doing with the to_python() 
method? 

# Form class 

# I use the self["multiLineInfo"] pattern instead of 
self.fields["multiLineInfo"] 
# because the former gives a BoundField which merges the Field and the 
# post/initial data
class OrganizationItemForm(ModelForm):
selected  = forms.BooleanField(required=False)  
extraRequired = forms.BooleanField(required=False, 
widget=forms.HiddenInput)
multiLineInfo = forms.BooleanField(required=False, 
widget=forms.HiddenInput)

def __init__(self, *args, **kwargs):
super(AuditModelForm, self).__init__(*args, **kwargs)
if self["multiLineInfo"].to_python():
self.fields["descr"].widget = 
forms.Textarea(attrs={"class":"descriptionEdit"})
else:
self.fields["descr"].widget = 
forms.TextInput(attrs={"class":"itemDescrEdit"}) 
self.fields["descr"].required = self["extraRequired"].to_python() 
and self["selected"].to_python()

class Meta:
model = OrganizationItem

# Model classes

class OrganizationItem(models.Model):
organization = models.ForeignKey(Organization)
item   = models.ForeignKey(ListItem)
descr  = models.TextField("Description", blank=True)

# View 

def organizationAdd(request):

OrganizationItemFormSet = formset_factory(OrganizationItemForm)

if request.method == 'POST':
form = OrganizationForm(request.POST)
orgItemFormSet = OrganizationItemFormSet(request.POST)
if form.is_valid():
form.save() 
for itm in orgItemFormSet:
if itm["selected"].to_python():
itm.instance.organization = form.instance
if orgItemFormSet.is_valid():
SaveItems(form.instance, orgItemFormSet)
redirect("orgEdit", form.instance.pk)
else:
form.instance.delete()
listItems = CreateItemsSection(orgItemFormSet, 
category__organization=True)
else:
form = OrganizationForm()
orgItemFormSet = OrganizationItemFormSet() 
listItems = CreateItemsSection(orgItemFormSet, "organization", 
category__organization=True)

context = {
'title': 'New organization', 
'form': form, 
'listItems': listItems, 
'listItemsManagementForm': orgItemFormSet.management_form, 
'isNew': True}

return render_to_response('organizationEdit.html', context,
context_instance=RequestContext(request))

# Template

{{ listItemsManagementForm }}

{% for item in listItems %}
<li{% if item.form.descr.errors %} class="errors" {% endif %}>
{{ item.form.descr.errors }}{% if item.form.descr.errors 
%}{% endif %}
{{ item.form.selected }} {{ item.label }}
{% if item.form.extraRequired.to_python or item.descrLabel %}
{% if item.form.multiLineInfo.to_python %}

{% else %}

{% endif %}
{{ item.descrLabel }}
{% if item.form.multi

Re: How to test form values in a template? (simplified)

[Shawn Milochik]

Are you saying that you want to show some form inputs conditionally 
based upon configuration, for example for each user?


If that's your goal then it's very easy to do by adding the logic in the 
form's __init__. Add/remove fields there and (possibly) override save() 
if you have to take any additional action.


There's no need to do things like start modifying how the guts of 
forms.Form works for something like this.


Shawn




--
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.

Running test cases on pydev raises an exception due to a problem in the standard library

[Ger]

Hi all, I have a django app that works correctly from the console, but
if I try to pass the tests cases from Eclipse+PyDev I got the
following exception:

Traceback (most recent call last):
  File "C:\Users\gfuentes\workspace\AG\src\cfx\manage.py", line 19, in

execute_manager(settings)
  File "c:\users\gfuentes\workspace\ag\lib\site-packages\django-1.3-
py2.5.egg\django\core\management\__init__.py", line 438, in
execute_manager
utility.execute()
  File "c:\users\gfuentes\workspace\ag\lib\site-packages\django-1.3-
py2.5.egg\django\core\management\__init__.py", line 379, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File "c:\users\gfuentes\workspace\ag\lib\site-packages\django-1.3-
py2.5.egg\django\core\management\base.py", line 191, in run_from_argv
self.execute(*args, **options.__dict__)
  File "c:\users\gfuentes\workspace\ag\lib\site-packages\django-1.3-
py2.5.egg\django\core\management\base.py", line 220, in execute
output = self.handle(*args, **options)
  File "c:\users\gfuentes\workspace\ag\lib\site-packages\django-1.3-
py2.5.egg\django\core\management\commands\test.py", line 19, in handle
from django.test.utils import get_runner
  File "c:\users\gfuentes\workspace\ag\lib\site-packages\django-1.3-
py2.5.egg\django\test\__init__.py", line 6, in 
from django.test.testcases import TestCase, TransactionTestCase,
skipIfDBFeature, skipUnlessDBFeature
  File "c:\users\gfuentes\workspace\ag\lib\site-packages\django-1.3-
py2.5.egg\django\test\testcases.py", line 14, in 
from django.test import _doctest as doctest
  File "c:\users\gfuentes\workspace\ag\lib\site-packages\django-1.3-
py2.5.egg\django\test\_doctest.py", line 104, in 
import unittest, difflib, pdb, tempfile
  File "C:\sw\Python25\lib\pdb.py", line 53, in 
class Pdb(bdb.Bdb, cmd.Cmd):
AttributeError: 'module' object has no attribute 'Cmd'

The django version is: 1.3
Python version: 2.5

I already checked on the Internet but without success. When I run it
from the console I use the same python installation

Do you have any ideas?
Thank you from advanced

-- 
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.

Re: DeprecationWarning displayed in test, not in dev

[Andre Terra]

Great! Thank you Tom and Russ for the heads up.


Cheers,
AT

On 7/20/11, Tom Evans  wrote:
> On Wed, Jul 20, 2011 at 3:24 AM, Russell Keith-Magee
>  wrote:
>> The problem here actually lies with Python.
>>
>> For some reason, Python 2.7 changed the reporting behavior of Warnings
>> so that DeprecationWarning is ignored by default [1]. So, because
>> you're developing in Python 2.7, you don't see the warnings by
>> default; in production, where you're using Python 2.5, you do.
>>
>> [1] http://docs.python.org/library/warnings.html#warning-categories
>>
>> Yours,
>> Russ Magee %-)
>
> Thanks Russ, that explains it perfectly. For the archives, you can
> override this on the command line, eg:
>
> python -W once manage.py etc
>
> Which gives me a lot of lovely warnings to work through :)
>
> Cheers
>
> Tom
>
> --
> 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.
>
>

-- 
Sent from my mobile device

-- 
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.

Re: DeprecationWarning displayed in test, not in dev

[Tom Evans]

On Wed, Jul 20, 2011 at 3:24 AM, Russell Keith-Magee
 wrote:
> The problem here actually lies with Python.
>
> For some reason, Python 2.7 changed the reporting behavior of Warnings
> so that DeprecationWarning is ignored by default [1]. So, because
> you're developing in Python 2.7, you don't see the warnings by
> default; in production, where you're using Python 2.5, you do.
>
> [1] http://docs.python.org/library/warnings.html#warning-categories
>
> Yours,
> Russ Magee %-)

Thanks Russ, that explains it perfectly. For the archives, you can
override this on the command line, eg:

python -W once manage.py etc

Which gives me a lot of lovely warnings to work through :)

Cheers

Tom

-- 
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.

Re: DeprecationWarning displayed in test, not in dev

[Russell Keith-Magee]

On Tue, Jul 19, 2011 at 11:53 PM, Tom Evans <tevans...@googlemail.com> wrote:
> Hi all
>
> I recently upgraded one of my apps to the next iteration. This used a
> third party library, which started spewing out DeprecationWarning
> messages when I deployed it to the test site. None of these warnings
> appeared when I was developing, and I was wondering if there was a
> reason why. The only noticeable difference I can see between the two
> is that I use python 2.7 in development, and 2.5 in test/production -
> dev is on my laptop, where as the others are on dedicated boxes.

The problem here actually lies with Python.

For some reason, Python 2.7 changed the reporting behavior of Warnings
so that DeprecationWarning is ignored by default [1]. So, because
you're developing in Python 2.7, you don't see the warnings by
default; in production, where you're using Python 2.5, you do.

[1] http://docs.python.org/library/warnings.html#warning-categories

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 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.

DeprecationWarning displayed in test, not in dev

[Tom Evans]

Hi all

I recently upgraded one of my apps to the next iteration. This used a
third party library, which started spewing out DeprecationWarning
messages when I deployed it to the test site. None of these warnings
appeared when I was developing, and I was wondering if there was a
reason why. The only noticeable difference I can see between the two
is that I use python 2.7 in development, and 2.5 in test/production -
dev is on my laptop, where as the others are on dedicated boxes.

In both cases, the required packages are installed into a virtualenv
via pip from a requirements file, so the environment can be wiped out
and re-created, which I did on both dev and test, without changing the
end result.

So, in dev:

> $ md5 ../environ/src/django-postgresql-netfields/netfields/fields.py
MD5 (../environ/src/django-postgresql-netfields/netfields/fields.py) =
3ad794d519a1328b1587a9f604324888
> $ python manage.py shell
Python 2.7.1 (r271:86832, Dec 13 2010, 15:52:15)
[GCC 4.2.1 20070719  [FreeBSD]] on freebsd8
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> import django
>>> django.VERSION
(1, 3, 0, 'final', 0)

In test:

> $ md5 ../environ/lib/python2.5/site-packages/netfields/fields.py
MD5 (../environ/lib/python2.5/site-packages/netfields/fields.py) =
3ad794d519a1328b1587a9f604324888
> $ python manage.py shell
.../environ/lib/python2.5/site-packages/netfields/fields.py:8:
DeprecationWarning: A Field class whose get_db_prep_lookup method
hasn't been updated to take `connection` and `prepared` arguments.
  class _NetAddressField(models.Field):
.../environ/lib/python2.5/site-packages/netfields/fields.py:8:
DeprecationWarning: A Field class whose get_db_prep_value method
hasn't been updated to take `connection` and `prepared` arguments.
  class _NetAddressField(models.Field):
.../environ/lib/python2.5/site-packages/django/db/models/fields/subclassing.py:80:
DeprecationWarning: A Field class whose db_type method hasn't been
updated to take a `connection` argument.
  new_class = super(SubfieldBase, cls).__new__(cls, name, bases, attrs)
.../environ/lib/python2.5/site-packages/netfields/fields.py:86:
DeprecationWarning: A Field class whose db_type method hasn't been
updated to take a `connection` argument.
  class MACAddressField(models.Field):
Python 2.5.2 (r252:60911, Apr 25 2008, 17:25:09)
[GCC 4.2.1 20070719  [FreeBSD]] on freebsd7
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> import django
>>> django.VERSION
(1, 3, 0, 'final', 0)


The actual warning isn't an issue, I can update the library to fix
that, I'm more concerned why I am not seeing the warnings in
development.

Cheers

Tom

-- 
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.

Re: How to add CSRF to context when using test client???

[Craig Blaszczyk]

csrf_token is a proxy object not a string.

Try doing:
csrf_token = '%s' % response.context['csrf_token']

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/DtPU80g0avcJ.
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.

Re: How to add CSRF to context when using test client???

[andres ledesma]

Hi Matteius, I stumbled across the same problem.
I wanted to carry out a test case using CSRF, and I failed.
I managed to add the csrf_token to my post request, but
apparently this is not enough. Here I will show you the code,
perhaps you will have better luck then...

c = Client(enforce_csrf_checks=True)
response = c.get('/auction/add/') # get a fresh form
print(response.content) # just to have a look
csrf_token = response.context['csrf_token'] # get the token
print('the token is: %s' % csrf_token) # show me the token

# now, we add the token value to the key csrfmiddlewaretoken
# as this is where django CSRF will check it

post_data = {
'csrfmiddlewaretoken': csrf_token,
'item': 'test item',
'price': '154.78',
'end_date': '2011-08-05 19:30:00',
}
# now we can send the post
response = c.post('/auction/add/', post_data)
# now we test the assert
self.assertEqual(response.status_code, 200)

As I said, this still does not work, I get a 403: which refers
to an invalid CSRF token key. If you managed to overcome this
problem, please let us know. So far, I decided
not to use c = Client(enforce_csrf_checks=True) but this is not
a nice solution, is it?
Best!
-Andres

On Jun 10, 8:02 pm, Matteius <matte...@gmail.com> wrote:
> Yes I Have this in the setUp function which causes my POST request to
> get a 403 forbidden because I don't actually include the CSRF field in
> the context as the middleware does on a deployed version of the site.
> I need a function to call or something to get the CSRF context value,
> or a function that I can pass a context which will add it in the
> CSRF.  Otherwise there is not much of a point to enable CSRF with the
> test client because you'll get 403 errors.
>
> -Matt
>
> On Jun 10, 1:46 am, Artemenko Alexander <sa...@svetlyak.ru> wrote:
>
>
>
>
>
>
>
> > Hi Matt,
>
> > Use:
>
> > from django.test import Client
> > csrf_client = Client(enforce_csrf_checks=True)
>
> >https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#testing
>
> > 10.06.2011, 08:48, "Matteius" <matte...@gmail.com>:
>
> > > Greetings,
>
> > > I am writing unit tests for my application, and I want to leave CSRF
> > > checks enabled in testing. This means on my POST I am getting 403
> > > because I have not figured out how to add csrf to my context when
> > > using the test client. Please advise on how to most easily do this:
>
> > > # Issue a POST request.
> > > response = self.client.post('/student/open_enrollments/',
> > > {'course': 3})
> > > # Check that the response is 200 OK.
> > > self.assertEqual(response.status_code, 200)
> > > # Verify template is the expected one.
> > > self.assertTemplateUsed(response, 'student_portal/
> > > open_enrollments.html')
> > > # Check that the rendered context contains now 0 Courses.
> > > self.assertEqual(len(response.context['courses']), 0)
>
> > > --
> > > 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 
> > > athttp://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.

Re: Test runner fails with Django 1.2.1 and psycopg2 2.4.2

[ashwoods]

do you get these errors with:

'OPTIONS': {
'autocommit': True,
}

?

On Jun 14, 6:06 pm, Andrew Brookins <a.m.brook...@gmail.com> wrote:
> Hey,
>
> Yesterday I started seeing test runner failures with Django 1.2.1 and
> psycog2 2.4.2.
>
> Here's the traceback (where [project_dir] is the path to my virtualenv):
>
> Traceback (most recent call last):
>   File "./manage.py", line 11, in 
>     execute_manager(settings)
>   File
> "[project_dir]/lib/python2.6/site-packages/django/core/management/__init__. 
> py",
> line 438, in execute_manager
>     utility.execute()
>   File
> "[project_dir]/lib/python2.6/site-packages/django/core/management/__init__. 
> py",
> line 379, in execute
>     self.fetch_command(subcommand).run_from_argv(self.argv)
>   File
> "[project_dir]/lib/python2.6/site-packages/django/core/management/base.py",
> line 191, in run_from_argv
>     self.execute(*args, **options.__dict__)
>   File
> "[project_dir]/lib/python2.6/site-packages/django/core/management/base.py",
> line 218, in execute
>     output = self.handle(*args, **options)
>   File
> "[project_dir]/lib/python2.6/site-packages/django/core/management/commands/ 
> test.py",
> line 37, in handle
>     failures = test_runner.run_tests(test_labels)
>   File "[project_dir]/lib/python2.6/site-packages/django/test/simple.py",
> line 313, in run_tests
>     old_config = self.setup_databases()
>   File "[project_dir]/lib/python2.6/site-packages/django/test/simple.py",
> line 270, in setup_databases
>     connection.creation.create_test_db(self.verbosity, autoclobber=not
> self.interactive)
>   File
> "[project_dir]/lib/python2.6/site-packages/django/db/backends/creation.py",
> line 346, in create_test_db
>     test_database_name = self._create_test_db(verbosity, autoclobber)
>   File
> "[project_dir]/lib/python2.6/site-packages/django/db/backends/creation.py",
> line 381, in _create_test_db
>     self.set_autocommit()
>   File
> "[project_dir]/lib/python2.6/site-packages/django/db/backends/creation.py",
> line 448, in set_autocommit
>     self.connection.connection.autocommit = True
> psycopg2.ProgrammingError: autocommit cannot be used inside a transaction
>
> Reverting to psycopg2 2.4.1 fixes the problem. Anyone seen this?
>
> Best,
> Andrew

-- 
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.

Re: Test runner fails with Django 1.2.1 and psycopg2 2.4.2

[Andrew Brookins]

Looks like there's already a ticket (my search-fu failed me):

https://code.djangoproject.com/ticket/16250

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/7D7CrjiJaXMJ.
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.

Test runner fails with Django 1.2.1 and psycopg2 2.4.2

[Andrew Brookins]

Hey, 

Yesterday I started seeing test runner failures with Django 1.2.1 and 
psycog2 2.4.2. 

Here's the traceback (where [project_dir] is the path to my virtualenv):

Traceback (most recent call last):
  File "./manage.py", line 11, in 
execute_manager(settings)
  File 
"[project_dir]/lib/python2.6/site-packages/django/core/management/__init__.py", 
line 438, in execute_manager
utility.execute()
  File 
"[project_dir]/lib/python2.6/site-packages/django/core/management/__init__.py", 
line 379, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File 
"[project_dir]/lib/python2.6/site-packages/django/core/management/base.py", 
line 191, in run_from_argv
self.execute(*args, **options.__dict__)
  File 
"[project_dir]/lib/python2.6/site-packages/django/core/management/base.py", 
line 218, in execute
output = self.handle(*args, **options)
  File 
"[project_dir]/lib/python2.6/site-packages/django/core/management/commands/test.py",
 
line 37, in handle
failures = test_runner.run_tests(test_labels)
  File "[project_dir]/lib/python2.6/site-packages/django/test/simple.py", 
line 313, in run_tests
old_config = self.setup_databases()
  File "[project_dir]/lib/python2.6/site-packages/django/test/simple.py", 
line 270, in setup_databases
connection.creation.create_test_db(self.verbosity, autoclobber=not 
self.interactive)
  File 
"[project_dir]/lib/python2.6/site-packages/django/db/backends/creation.py", 
line 346, in create_test_db
test_database_name = self._create_test_db(verbosity, autoclobber)
  File 
"[project_dir]/lib/python2.6/site-packages/django/db/backends/creation.py", 
line 381, in _create_test_db
self.set_autocommit()
  File 
"[project_dir]/lib/python2.6/site-packages/django/db/backends/creation.py", 
line 448, in set_autocommit
self.connection.connection.autocommit = True
psycopg2.ProgrammingError: autocommit cannot be used inside a transaction

Reverting to psycopg2 2.4.1 fixes the problem. Anyone seen this?

Best,
Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/bYngn9hESksJ.
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.

Re: How to add CSRF to context when using test client???

[Matteius]

Yes I Have this in the setUp function which causes my POST request to
get a 403 forbidden because I don't actually include the CSRF field in
the context as the middleware does on a deployed version of the site.
I need a function to call or something to get the CSRF context value,
or a function that I can pass a context which will add it in the
CSRF.  Otherwise there is not much of a point to enable CSRF with the
test client because you'll get 403 errors.

-Matt

On Jun 10, 1:46 am, Artemenko Alexander <sa...@svetlyak.ru> wrote:
> Hi Matt,
>
> Use:
>
> from django.test import Client
> csrf_client = Client(enforce_csrf_checks=True)
>
> https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#testing
>
> 10.06.2011, 08:48, "Matteius" <matte...@gmail.com>:
>
>
>
> > Greetings,
>
> > I am writing unit tests for my application, and I want to leave CSRF
> > checks enabled in testing. This means on my POST I am getting 403
> > because I have not figured out how to add csrf to my context when
> > using the test client. Please advise on how to most easily do this:
>
> > # Issue a POST request.
> > response = self.client.post('/student/open_enrollments/',
> > {'course': 3})
> > # Check that the response is 200 OK.
> > self.assertEqual(response.status_code, 200)
> > # Verify template is the expected one.
> > self.assertTemplateUsed(response, 'student_portal/
> > open_enrollments.html')
> > # Check that the rendered context contains now 0 Courses.
> > self.assertEqual(len(response.context['courses']), 0)
>
> > --
> > 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 
> > athttp://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.

Re: How to add CSRF to context when using test client???

[Artemenko Alexander]

Hi Matt,

Use:

from django.test import Client
csrf_client = Client(enforce_csrf_checks=True)

https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#testing

10.06.2011, 08:48, "Matteius" <matte...@gmail.com>:
> Greetings,
>
> I am writing unit tests for my application, and I want to leave CSRF
> checks enabled in testing.  This means on my POST I am getting 403
> because I have not figured out how to add csrf to my context when
> using the test client.  Please advise on how to most easily do this:
>
> # Issue a POST request.
> response = self.client.post('/student/open_enrollments/',
> {'course': 3})
> # Check that the response is 200 OK.
> self.assertEqual(response.status_code, 200)
> # Verify template is the expected one.
> self.assertTemplateUsed(response, 'student_portal/
> open_enrollments.html')
> # Check that the rendered context contains now 0 Courses.
> self.assertEqual(len(response.context['courses']), 0)
>
> --
> 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.

How to add CSRF to context when using test client???

[Matteius]

Greetings,

I am writing unit tests for my application, and I want to leave CSRF
checks enabled in testing.  This means on my POST I am getting 403
because I have not figured out how to add csrf to my context when
using the test client.  Please advise on how to most easily do this:

# Issue a POST request.
response = self.client.post('/student/open_enrollments/',
{'course': 3})
# Check that the response is 200 OK.
self.assertEqual(response.status_code, 200)
# Verify template is the expected one.
self.assertTemplateUsed(response, 'student_portal/
open_enrollments.html')
# Check that the rendered context contains now 0 Courses.
self.assertEqual(len(response.context['courses']), 0)

-- 
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.

Re: Setting up dev/test/production environments on the server (dreamhost)

[Javier Guerra Giraldez]

On Sat, Jun 4, 2011 at 12:29 AM, AJ  wrote:
> My application does require emailing users and members of the website. This
> is mostly system mail and users will not email amongst themselves.

on webapp servers i usually install ssmtp.  it's not for handling
user's email, nor for receiving messages.  it simply allows the
application to send messages to users' existing email accounts (hosted
somewhere else).

the advantage is that there's no daemon to keep running and taking care of.

-- 
Javier

-- 
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.

Re: save out a test database?

[Margie Roginski]

At the time I asked the question I just had the sense that I wanted to
debug an issue by bringing up the web interface midway through my
test.   I attempted to do things like stop midway through the test via
set_trace() and then ctrl-c, then look at the db from a runserver run
that was pointing to the test database, but I find that the test
database is empty, as if the data has not yet been written out to it
by the test.

Perhaps if I call dumpdata from the call_command as you suggest, that
will get around this.

Maybe I don't even need this.  It just seemed nice to be able to debug
a test from the web interface, but in reality, now that I am off and
running writing tests, I guess I haven't ended up needing it after
all ...

In any case, thanks for your response.

Margie

On Jun 4, 5:47 am, Karen Tracey <kmtra...@gmail.com> wrote:
> On Thu, Jun 2, 2011 at 10:04 AM, Margie Roginski
> <margierogin...@yahoo.com>wrote:
>
> > Karen Tracy, if you are reading this, could you comment?
>
> > As the person that seems to be most knowledgable about django testing
> > (your Django 1.1 Testing book is fantastic - I highly recommend it!),
> > can you confirm that something like this is the best way to go?  It
> > seems strange to me that there is no more standard way of dumping the
> > database from inside a test so that the state can be replicated for
> > use in a runserver environment.
>
> Well, usually you want to go the other way: ensure your test run replicates
> your real running environment. I'm a little unclear on why you want to save
> the DB state from during a test?
>
> Probably  easier than using serialize directly, particularly if you want the
> whole DB, would be to call the dumpdata command via 
> call_command:https://docs.djangoproject.com/en/1.3/ref/django-admin/#running-manag...
>
> Karen
> --http://tracey.org/kmt/

-- 
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.

Re: Aw: Re: Setting up dev/test/production environments on the server (dreamhost)

[ApogeeGMail]

+1 for Webfaction
On Jun 4, 2011, at 4:48 AM, Martin Brochhaus wrote:

> +1
> 
> Hosting 20 (or more) on Webfaction. Awesome service. Awesome speed. Peace of 
> mind.
> 
> Best regards,
> Martin
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/django-users/-/aWJyUXNMNmdTWDBK.
> 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.

Re: save out a test database?

[Karen Tracey]

On Thu, Jun 2, 2011 at 10:04 AM, Margie Roginski
<margierogin...@yahoo.com>wrote:

> Karen Tracy, if you are reading this, could you comment?
>
> As the person that seems to be most knowledgable about django testing
> (your Django 1.1 Testing book is fantastic - I highly recommend it!),
> can you confirm that something like this is the best way to go?  It
> seems strange to me that there is no more standard way of dumping the
> database from inside a test so that the state can be replicated for
> use in a runserver environment.
>
>
Well, usually you want to go the other way: ensure your test run replicates
your real running environment. I'm a little unclear on why you want to save
the DB state from during a test?

Probably  easier than using serialize directly, particularly if you want the
whole DB, would be to call the dumpdata command via call_command:
https://docs.djangoproject.com/en/1.3/ref/django-admin/#running-management-commands-from-your-code

Karen
-- 
http://tracey.org/kmt/

-- 
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.

Aw: Re: Setting up dev/test/production environments on the server (dreamhost)

[Martin Brochhaus]

+1

Hosting 20 (or more) on Webfaction. Awesome service. Awesome speed. Peace of 
mind.

Best regards,
Martin

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/aWJyUXNMNmdTWDBK.
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.

Re: Setting up dev/test/production environments on the server (dreamhost)

[Kenneth Gonsalves]

On Sat, 2011-06-04 at 01:29 -0400, AJ wrote:
> I think I will go for VPS. I do agree that managing seems a little
> work but
> I guess eventually it will prove to be good.
> 
> I have one more question: Is it easy to have the mail server setup on
> a VPS?
> My application does require emailing users and members of the website.
> This
> is mostly system mail and users will not email amongst themselves.
> 
> 

apt-get (or yum) install postfix, or for the whole works:
http://workaround.org/ispmail/lenny
-- 
regards
KG
http://lawgon.livejournal.com
Coimbatore LUG rox
http://ilugcbe.techstud.org/

-- 
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.

Re: Setting up dev/test/production environments on the server (dreamhost)

[AJ]

I think I will go for VPS. I do agree that managing seems a little work but
I guess eventually it will prove to be good.

I have one more question: Is it easy to have the mail server setup on a VPS?
My application does require emailing users and members of the website. This
is mostly system mail and users will not email amongst themselves.


On Sat, Jun 4, 2011 at 12:21 AM, Kenneth Gonsalves
wrote:

> On Fri, 2011-06-03 at 14:12 -0400, AJ wrote:
> > To change the question or ask a new one too: what name do you suggest
> > as a
> > good, reliable yet economical hosting provider - Both for personal
> > static
> > website hosting and little Django web projects?
>
> webfaction
> --
> regards
> KG
> http://lawgon.livejournal.com
> Coimbatore LUG rox
> http://ilugcbe.techstud.org/
>
> --
> 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.
>
>


-- 
AJ

-- 
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.

Re: Setting up dev/test/production environments on the server (dreamhost)

[Kenneth Gonsalves]

On Fri, 2011-06-03 at 14:12 -0400, AJ wrote:
> To change the question or ask a new one too: what name do you suggest
> as a
> good, reliable yet economical hosting provider - Both for personal
> static
> website hosting and little Django web projects? 

webfaction
-- 
regards
KG
http://lawgon.livejournal.com
Coimbatore LUG rox
http://ilugcbe.techstud.org/

-- 
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.

Re: Setting up dev/test/production environments on the server (dreamhost)

[Dave Sayer]

On 3 June 2011 19:48, Javier Guerra Giraldez  wrote:
> small VPSs tend to be the best answer if you don't mind adminstering
> your own box.  both webfaction and linode have solid reputation and
> support teams.
>
+1 for VPS. I had always used Dreamhost for hosting PHP & static sites
for both personal and clients. When i started messing with Django, I
decided to take the plunge and get a small VPS from Bytemark in the
UK. Despite being daunted initially by the admin side, I haven't
looked back. The admin side of things took a little bit of getting
used to but Slicehost have some fantastic articles on getting up and
running. It's not as cheap as shared hosting but with complete control
over the VPS, email and phone support and great performance, I feel
the extra money is well worth it. I pay £15 (about $22 USD) per month
for each VPS - i run two; one for me and small clients and the other
is dedicated to one clients site. I just use my USD$10 per month DH
account for svn and backing up my vps' via rsync.

I can add another +1 for Nginx too.

Cheers,

Dave


-- 
---
Dave Sayer | Bath Design
Web design & development with standards
---
mobile: +44 (0)7702787436
email: d...@bathdesign.co.uk
web: http://bathdesign.co.uk
photography: http://davesayer.com
twitter: http://twitter.com/sweet_grass
---

-- 
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.

Re: Setting up dev/test/production environments on the server (dreamhost)

[Oscar Carballal]

I recently discovered AlienLayer, a VPS provider in las vegas, they hace a
$19/year plan that is quite good for personal stuff. Take a look to it :)

Enviado desde mi HTC
El 03/06/2011 20:48, "Javier Guerra Giraldez"  escribió:
> On Fri, Jun 3, 2011 at 1:12 PM, AJ  wrote:
>> To change the question or ask a new one too: what name do you suggest as
a
>> good, reliable yet economical hosting provider - Both for personal static
>> website hosting and little Django web projects?
>
> small VPSs tend to be the best answer if you don't mind adminstering
> your own box. both webfaction and linode have solid reputation and
> support teams.
>
>
> --
> Javier
>
> --
> 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.

Re: Setting up dev/test/production environments on the server (dreamhost)

[Cal Leeming [Simplicity Media Ltd]]

Oh also, if you want to run off dev.* / staging.* urls, but your code (for
whatever reason) won't support those new urls, you can use middleware to
trick the code into thinking the dev.*/staging.* hostnames are actually the
prod hostnames, whilst still applying the correct environmental settings:


# Do some clever stripping of dev.*
if host[:4] == "dev.":
host = host[4:]
#request.META["HTTP_HOST"] = host
#request.META['SERVER_NAME'] = host
if request.META.has_key('HTTP_REFERER'):
request.META['HTTP_REFERER'] =
request.META.get('HTTP_REFERER').replace("//dev.", "//")

if request.META.has_key('SCRIPT_URI'):
request.META['SCRIPT_URI'] =
request.META.get('SCRIPT_URI').replace("//dev.", "//")

etc..

On Fri, Jun 3, 2011 at 9:54 PM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> Oh, sorry I thought you were asking how to stop people accessing your dev
> environment.
>
> There are multiple ways to handle dev/staging/prod separation, and they all
> depend on how mission critical your prod is.
>
> Personally, I have different sub domains for each one, place prod under git
> only release control, and have dev/staging locked down.
>
> In the settings.py, I then separate the environments out by using
> environmental variables. For example:
>
> DJANGO_ENVIRONMENT=prod ./manage.py shell
> DJANGO_ENVIRONMENT=dev ./manage.py shell
>
> You can also do auto env detection, based on the current path, by using the
> following:
>
>
> CURRENT_DIR = os.path.dirname(__file__)
>
> if not os.environ.has_key('DJANGO_ENVIRONMENT'):
> if CURRENT_DIR.count("/ddcms/dev"):
> os.environ['DJANGO_ENVIRONMENT'] = 'dev'
>
> elif CURRENT_DIR.count("/ddcms/prod"):
> os.environ['DJANGO_ENVIRONMENT'] = 'prod'
>
> else:
> assert os.environ.has_key('DJANGO_ENVIRONMENT'), "Auto environment
> resolve failed, you must specify which DJANGO_ENVIRONMENT to use (dev/prod)"
>
> To resolve relative include problems, you can also use this to grab the
> current root dir of your project:
>
> # Hard code the root folder for production, due to symlinking resolve
> problems.
> if os.environ.get('DJANGO_ENVIRONMENT') == 'prod':
> PROJECT_PATH = "/ddcms/prod/webapp"
> else:
> PROJECT_PATH =
> os.path.abspath(os.path.dirname(__file__)+"/").replace('\\',"/")
>
> If you need your dev/prod to use the same database source, you can also use
> middleware and db routers to control how much damage dev can cause etc.
>
> Cal
>
> On Fri, Jun 3, 2011 at 9:50 PM, AJ <brandmys...@gmail.com> wrote:
>
>> Well even if I do my Python stuff in virtualenv for development on a
>> linode box, I'd like to know how to separate development/test environment to
>> live/production.
>>
>> Is the only solution "*...**IP whitelisting to block only those who you
>> want to have access...*"?
>>
>> Also, can I run multiple instances of same Django website on
>> dev.website.com, test.website.com and www.website.com?
>>
>>
>>
>>
>> On Fri, Jun 3, 2011 at 4:28 PM, Shawn Milochik <sh...@milochik.com>wrote:
>>
>>> On 06/03/2011 04:16 PM, Amanjeev Sethi wrote:
>>>
>>>> Linode looks nice plus it will teach me some administration side too.
>>>>
>>>> If I try using linode, what is the best setup (Linux Distro, web server
>>>> support, modules like mod_wsgi? etc ) for Django websites on linode?
>>>>
>>>>
>>>>
>>> Use whatever distro you like and do all your Python stuff in virtualenv.
>>>
>>> For deployment I use and recommend nginx + gunicorn.
>>>
>>> Use supervisord to run gunicorn.
>>>
>>> Shawn
>>>
>>>
>>>
>>> --
>>> 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.
>>>
>>>
>>
>>
>> --
>> AJ
>>
>> --
>> 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.

Re: Setting up dev/test/production environments on the server (dreamhost)

[Cal Leeming [Simplicity Media Ltd]]

Oh, sorry I thought you were asking how to stop people accessing your dev
environment.

There are multiple ways to handle dev/staging/prod separation, and they all
depend on how mission critical your prod is.

Personally, I have different sub domains for each one, place prod under git
only release control, and have dev/staging locked down.

In the settings.py, I then separate the environments out by using
environmental variables. For example:

DJANGO_ENVIRONMENT=prod ./manage.py shell
DJANGO_ENVIRONMENT=dev ./manage.py shell

You can also do auto env detection, based on the current path, by using the
following:


CURRENT_DIR = os.path.dirname(__file__)

if not os.environ.has_key('DJANGO_ENVIRONMENT'):
if CURRENT_DIR.count("/ddcms/dev"):
os.environ['DJANGO_ENVIRONMENT'] = 'dev'

elif CURRENT_DIR.count("/ddcms/prod"):
os.environ['DJANGO_ENVIRONMENT'] = 'prod'

else:
assert os.environ.has_key('DJANGO_ENVIRONMENT'), "Auto environment
resolve failed, you must specify which DJANGO_ENVIRONMENT to use (dev/prod)"

To resolve relative include problems, you can also use this to grab the
current root dir of your project:

# Hard code the root folder for production, due to symlinking resolve
problems.
if os.environ.get('DJANGO_ENVIRONMENT') == 'prod':
PROJECT_PATH = "/ddcms/prod/webapp"
else:
PROJECT_PATH =
os.path.abspath(os.path.dirname(__file__)+"/").replace('\\',"/")

If you need your dev/prod to use the same database source, you can also use
middleware and db routers to control how much damage dev can cause etc.

Cal

On Fri, Jun 3, 2011 at 9:50 PM, AJ <brandmys...@gmail.com> wrote:

> Well even if I do my Python stuff in virtualenv for development on a linode
> box, I'd like to know how to separate development/test environment to
> live/production.
>
> Is the only solution "*...**IP whitelisting to block only those who you
> want to have access...*"?
>
> Also, can I run multiple instances of same Django website on
> dev.website.com, test.website.com and www.website.com?
>
>
>
>
> On Fri, Jun 3, 2011 at 4:28 PM, Shawn Milochik <sh...@milochik.com> wrote:
>
>> On 06/03/2011 04:16 PM, Amanjeev Sethi wrote:
>>
>>> Linode looks nice plus it will teach me some administration side too.
>>>
>>> If I try using linode, what is the best setup (Linux Distro, web server
>>> support, modules like mod_wsgi? etc ) for Django websites on linode?
>>>
>>>
>>>
>> Use whatever distro you like and do all your Python stuff in virtualenv.
>>
>> For deployment I use and recommend nginx + gunicorn.
>>
>> Use supervisord to run gunicorn.
>>
>> Shawn
>>
>>
>>
>> --
>> 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.
>>
>>
>
>
> --
> AJ
>
> --
> 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.

Re: Setting up dev/test/production environments on the server (dreamhost)

[Shawn Milochik]

On 06/03/2011 04:50 PM, AJ wrote:
Well even if I do my Python stuff in virtualenv for development on a 
linode box, I'd like to know how to separate development/test 
environment to live/production.


Is the only solution "/...//IP whitelisting to block only those who 
you want to have access.../"?


Also, can I run multiple instances of same Django website on 
dev.website.com <http://dev.website.com>, test.website.com 
<http://test.website.com> and www.website.com <http://www.website.com>?




Yes, you can run a bunch of instances. To do this I use multiple user 
accounts. It's very easy to configure in nginx even if you only have one 
IP address.


As for the first question, it sounds like IP filtering may be the way, 
because the box is publicly accessible from the Internet. You could do 
something with the INTERNAL_IPS setting in settings.py.


--
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.

Re: Setting up dev/test/production environments on the server (dreamhost)

[AJ]

Well even if I do my Python stuff in virtualenv for development on a linode
box, I'd like to know how to separate development/test environment to
live/production.

Is the only solution "*...**IP whitelisting to block only those who you want
to have access...*"?

Also, can I run multiple instances of same Django website on dev.website.com,
test.website.com and www.website.com?




On Fri, Jun 3, 2011 at 4:28 PM, Shawn Milochik <sh...@milochik.com> wrote:

> On 06/03/2011 04:16 PM, Amanjeev Sethi wrote:
>
>> Linode looks nice plus it will teach me some administration side too.
>>
>> If I try using linode, what is the best setup (Linux Distro, web server
>> support, modules like mod_wsgi? etc ) for Django websites on linode?
>>
>>
>>
> Use whatever distro you like and do all your Python stuff in virtualenv.
>
> For deployment I use and recommend nginx + gunicorn.
>
> Use supervisord to run gunicorn.
>
> Shawn
>
>
>
> --
> 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.
>
>


-- 
AJ

-- 
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.

Re: Setting up dev/test/production environments on the server (dreamhost)

[Shawn Milochik]

On 06/03/2011 04:16 PM, Amanjeev Sethi wrote:

Linode looks nice plus it will teach me some administration side too.

If I try using linode, what is the best setup (Linux Distro, web 
server support, modules like mod_wsgi? etc ) for Django websites on 
linode?





Use whatever distro you like and do all your Python stuff in virtualenv.

For deployment I use and recommend nginx + gunicorn.

Use supervisord to run gunicorn.

Shawn



--
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.

Re: Setting up dev/test/production environments on the server (dreamhost)

[Amanjeev Sethi]

Linode looks nice plus it will teach me some administration side too.

If I try using linode, what is the best setup (Linux Distro, web server
support, modules like mod_wsgi? etc ) for Django websites on linode?




On Fri, Jun 3, 2011 at 2:48 PM, Javier Guerra Giraldez
wrote:

> On Fri, Jun 3, 2011 at 1:12 PM, AJ  wrote:
> > To change the question or ask a new one too: what name do you suggest as
> a
> > good, reliable yet economical hosting provider - Both for personal static
> > website hosting and little Django web projects?
>
> small VPSs tend to be the best answer if you don't mind adminstering
> your own box.  both webfaction and linode have solid reputation and
> support teams.
>
>
> --
> Javier
>
> --
> 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.
>
>


-- 
AJ

-- 
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.

Re: Setting up dev/test/production environments on the server (dreamhost)

[Javier Guerra Giraldez]

On Fri, Jun 3, 2011 at 1:12 PM, AJ  wrote:
> To change the question or ask a new one too: what name do you suggest as a
> good, reliable yet economical hosting provider - Both for personal static
> website hosting and little Django web projects?

small VPSs tend to be the best answer if you don't mind adminstering
your own box.  both webfaction and linode have solid reputation and
support teams.


-- 
Javier

-- 
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.

Re: Setting up dev/test/production environments on the server (dreamhost)

[AJ]

Thanks Cal.

I have felt that myself. I have about half a dozen websites/domains (mostly
personal and family) hosted with them. I have started Django as my main
stack for web development and have realized that it is not extremely great
as a Django hosting. Also, they do not have phone tech. support.

Currently, I have the plan with Dreamhost which is about $120 per month with
unlimited bandwidth and disk space.

To change the question or ask a new one too: what name do you suggest as a
good, reliable yet economical hosting provider - Both for personal static
website hosting and little Django web projects?

Best,
AJ


On Fri, Jun 3, 2011 at 2:05 PM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> Hi AJ,
>
> Just a heads up, I have had a few clients in the past who used Dreamhost
> (and I had to set it up for them). They are not exactly the worlds best
> provider, and you certainly wouldn't want to use them for any production
> (live) sites.
>
> But, to answer your original question, you can use IP whitelisting to block
> only those who you want to have access, by adding a rejection rule directly
> into the virtual host config.
>
> Cal
>
> -- Forwarded message --
> From: AJ <brandmys...@gmail.com>
> Date: Fri, Jun 3, 2011 at 7:01 PM
> Subject: Setting up dev/test/production environments on the server
> (dreamhost)
> To: django-users@googlegroups.com
>
>
> Happy Friday to All:
>
> I have a project under way. All this time I have been developing on my
> personal Macbook with Django's dev server. I'd like to push this to the
> hosting service I have from Dreamhost and test, develop, fix it there.
>
> I'd like to know how can I avoid it being visible only to me while I hammer
> things out. It will be nice if I can have a dev instance visible only to me
> and a test/staging where I can showcase it to a few folks and then release
> it to the production. I do not know how to do this.
>
> First I was thinking of creating a subdomain system like dev/test/ etc. but
> Dreamhost uses passenger and I am not sure how to install multiple instances
> of a Django app per domain on Dreamhost either.
>
> What are you suggestions? Please feel free to point me to earlier
> discussions or articles or tools that I can use to achieve this.
>
> Thanks a lot.
> AJ
>
> --
> 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.
>
>


-- 
AJ

-- 
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.

Fwd: Setting up dev/test/production environments on the server (dreamhost)

[Cal Leeming [Simplicity Media Ltd]]

Hi AJ,

Just a heads up, I have had a few clients in the past who used Dreamhost
(and I had to set it up for them). They are not exactly the worlds best
provider, and you certainly wouldn't want to use them for any production
(live) sites.

But, to answer your original question, you can use IP whitelisting to block
only those who you want to have access, by adding a rejection rule directly
into the virtual host config.

Cal

-- Forwarded message --
From: AJ <brandmys...@gmail.com>
Date: Fri, Jun 3, 2011 at 7:01 PM
Subject: Setting up dev/test/production environments on the server
(dreamhost)
To: django-users@googlegroups.com


Happy Friday to All:

I have a project under way. All this time I have been developing on my
personal Macbook with Django's dev server. I'd like to push this to the
hosting service I have from Dreamhost and test, develop, fix it there.

I'd like to know how can I avoid it being visible only to me while I hammer
things out. It will be nice if I can have a dev instance visible only to me
and a test/staging where I can showcase it to a few folks and then release
it to the production. I do not know how to do this.

First I was thinking of creating a subdomain system like dev/test/ etc. but
Dreamhost uses passenger and I am not sure how to install multiple instances
of a Django app per domain on Dreamhost either.

What are you suggestions? Please feel free to point me to earlier
discussions or articles or tools that I can use to achieve this.

Thanks a lot.
AJ

-- 
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.

Setting up dev/test/production environments on the server (dreamhost)

[AJ]

Happy Friday to All:

I have a project under way. All this time I have been developing on my
personal Macbook with Django's dev server. I'd like to push this to the
hosting service I have from Dreamhost and test, develop, fix it there.

I'd like to know how can I avoid it being visible only to me while I hammer
things out. It will be nice if I can have a dev instance visible only to me
and a test/staging where I can showcase it to a few folks and then release
it to the production. I do not know how to do this.

First I was thinking of creating a subdomain system like dev/test/ etc. but
Dreamhost uses passenger and I am not sure how to install multiple instances
of a Django app per domain on Dreamhost either.

What are you suggestions? Please feel free to point me to earlier
discussions or articles or tools that I can use to achieve this.

Thanks a lot.
AJ

-- 
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.

Re: save out a test database?

[Steve Bywater]

What I've done to do this is insert a pdb.set_trace() right before the
place your test fails, then in pdb do Ctrl+C to break out of the test.
This leaves your test database intact at that state. Then you can
change your settings to point to the test database instead of your
regular one. Then you can runserver or dumpdata etc..

Good luck!
- Steve Bywater

-- 
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.

Re: save out a test database?

[Margie Roginski]

Karen Tracy, if you are reading this, could you comment?

As the person that seems to be most knowledgable about django testing
(your Django 1.1 Testing book is fantastic - I highly recommend it!),
can you confirm that something like this is the best way to go?  It
seems strange to me that there is no more standard way of dumping the
database from inside a test so that the state can be replicated for
use in a runserver environment.

Margie

On Jun 1, 2:01 pm, Kirill Spitsin <t...@0x746e.org.ua> wrote:
> On Wed, Jun 01, 2011 at 11:59:28AM -0700, Margie Roginski wrote:
> > That's a good pointer, thanks.  However I'm still confused about how I
> > can actually dump out the data from my test run?  For example, say I
> > have a particular test and I want to dump the data at some certain
> > point.  I can put in pdb.set_trace() in the code to stop at the
> > appropriate point, but what do I call from that point to create the
> > mydata.json file that then gets loaded with the command
>
> >   django-admin.py testserver mydata.json
> >>> from django.core.serializers import serialize
> >>> queryset1 = Model1.objects.filter(...)
> >>> queryset2 = Model2.objects.filter(...)
> >>> fixture = serialize('json', list(queryset1) + list(queryset2))
> >>> f = open('mydate.json', 'w')
> >>> f.write(fixture)
> >>> f.close()
>
> --
> Kirill Spitsin

-- 
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.

Re: spawning threads within test cases in django test framework

[Brian]

Thanks for the replies. I realised that I could reorganise the code so that 
all the database updating was done in the main thread. Re 
TransactionTestCases, I knew I'd read something related to that but didn't 
find it when I went looking yesterday evening; it sounds like that would 
have worked in this case.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/RGQ0THdUdF9NaHdK.
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.

Re: spawning threads within test cases in django test framework

[Kirill Spitsin]

On Tue, May 31, 2011 at 02:01:00PM -0700, Brian wrote:
> I've got a django app with a periodically scheduled background task that 
> updates the database. I've written a bunch of tests for its principal class 
> that are run as part of the django unit test framework. I want to convert 
> the class to do its work using multiple threads, but I'm having trouble 
> getting the tests to run against the multi-threaded version.
> 
> I've tried sqlite3 and postgres as back-ends, but to no avail. Is there a 
> problem where the testing framework uses transactions to rollback any 
> changes from one test to the next and so the evolving state of the database 
> in that transaction is hidden from the other threads? 

Right.

> Can the database connection (and hence transaction) be shared between
> the threads? Has anyone encountered this problem before? (And,
> ideally, came up with a really neat solution...)

Try to use TransactionTestCase instead of TestCase (and don't use
in-memory SQLite datebase).

-- 
Kirill Spitsin

-- 
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.

Re: save out a test database?

[Kirill Spitsin]

On Wed, Jun 01, 2011 at 11:59:28AM -0700, Margie Roginski wrote:
> That's a good pointer, thanks.  However I'm still confused about how I
> can actually dump out the data from my test run?  For example, say I
> have a particular test and I want to dump the data at some certain
> point.  I can put in pdb.set_trace() in the code to stop at the
> appropriate point, but what do I call from that point to create the
> mydata.json file that then gets loaded with the command
> 
>   django-admin.py testserver mydata.json

>>> from django.core.serializers import serialize
>>> queryset1 = Model1.objects.filter(...)
>>> queryset2 = Model2.objects.filter(...)
>>> fixture = serialize('json', list(queryset1) + list(queryset2))
>>> f = open('mydate.json', 'w')
>>> f.write(fixture)
>>> f.close()

-- 
Kirill Spitsin

-- 
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.

Re: spawning threads within test cases in django test framework

[Duane Griffin]

On 31 May 2011 22:01, Brian <brian.mcg...@gmail.com> wrote:
> I've got a django app with a periodically scheduled background task that
> updates the database. I've written a bunch of tests for its principal class
> that are run as part of the django unit test framework. I want to convert
> the class to do its work using multiple threads, but I'm having trouble
> getting the tests to run against the multi-threaded version.

I've had a similar problem trying to get some locking unit tests
working. Unfortunately I don't have a neat solution: I gave up in the
end :(

The first problem was, as you guessed, that the database connection
(or more specifically the cursor), can't be shared between threads.
IIRC it is stored as a thread-local variable and won't be correctly
initialised for the new threads. I managed to get it initialised by
doing the following:

import django.db
django.db.close_connection()
cursor = connection.cursor()

...however, that initialised it to use the *real* database, not the
test one. Very confusing test failures it produced, too :) Anyway, I
tried a few different things to try and get it all working, but gave
up after a while. I intend to come back to it at some point so if you
manage to get this working I'd be very interested in the solution!

> Thanks,
> Brian

Cheers,
Duane.

-- 
"I never could learn to drink that blood and call it wine" - Bob Dylan

-- 
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.

Re: save out a test database?

[Margie Roginski]

That's a good pointer, thanks.  However I'm still confused about how I
can actually dump out the data from my test run?  For example, say I
have a particular test and I want to dump the data at some certain
point.  I can put in pdb.set_trace() in the code to stop at the
appropriate point, but what do I call from that point to create the
mydata.json file that then gets loaded with the command

  django-admin.py testserver mydata.json

Thanks!

Margie


On May 29, 7:28 pm, Jason Culverhouse <ja...@mischievous.org> wrote:
> On May 29, 2011, at 7:13 PM, Margie Roginski <margierogin...@yahoo.com> wrote:
>
> > Anyone know if there is a way to save out a test database that is
> > created through the django TestCase module?
>
> I think this gets you close:
>
> https://docs.djangoproject.com/en/1.2/ref/django-admin/#testserver-fi...
>
> django-admin.py testserver
> Runs a Django development server (as in runserver) using data from the given 
> fixture(s).
>
>
>
>
>
>
>
> > IE, say I have a test that runs part way through.   I'd like to save
> > it out and then modify my settings.py to refer to the saved out test
> > database and take a look at it via my web client (ie, runserver) - is
> > that possible?
>
> > Thanks for any pointers,
>
> > Margie
>
> > --
> > 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 
> > athttp://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.

spawning threads within test cases in django test framework

[Brian]

I've got a django app with a periodically scheduled background task that 
updates the database. I've written a bunch of tests for its principal class 
that are run as part of the django unit test framework. I want to convert 
the class to do its work using multiple threads, but I'm having trouble 
getting the tests to run against the multi-threaded version.

I've tried sqlite3 and postgres as back-ends, but to no avail. Is there a 
problem where the testing framework uses transactions to rollback any 
changes from one test to the next and so the evolving state of the database 
in that transaction is hidden from the other threads? Can the database 
connection (and hence transaction) be shared between the threads? Has anyone 
encountered this problem before? (And, ideally, came up with a really neat 
solution...)

Thanks,

Brian 

-- 
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.

Re: save out a test database?

[Jason Culverhouse]

On May 29, 2011, at 7:13 PM, Margie Roginski <margierogin...@yahoo.com> wrote:

> Anyone know if there is a way to save out a test database that is
> created through the django TestCase module?
> 

I think this gets you close:

https://docs.djangoproject.com/en/1.2/ref/django-admin/#testserver-fixture-fixture

django-admin.py testserver
Runs a Django development server (as in runserver) using data from the given 
fixture(s).



> IE, say I have a test that runs part way through.   I'd like to save
> it out and then modify my settings.py to refer to the saved out test
> database and take a look at it via my web client (ie, runserver) - is
> that possible?
> 
> Thanks for any pointers,
> 
> Margie
> 
> -- 
> 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.

save out a test database?

[Margie Roginski]

Anyone know if there is a way to save out a test database that is
created through the django TestCase module?

IE, say I have a test that runs part way through.   I'd like to save
it out and then modify my settings.py to refer to the saved out test
database and take a look at it via my web client (ie, runserver) - is
that possible?

Thanks for any pointers,

Margie

-- 
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.

Re: how to get the test runner to only rebuild & populate the test_database if it changed?

[Phlip]

> Me again. Still helping clients TDD despite obese databases.

[localhost] run: python manage.py test --settings=test_settings my_app
--verbosity=0
--
Ran 2 tests in 0.018s

OK

Eat my vapor trail, b-words! Here's how I did it:

Upgrade the settings.py to use the TEST_NAME option:

DATABASES = {
'default': {
'NAME': 'test_myapp.db',
'TEST_NAME': 'test_myapp.db',
'ENGINE': 'django.db.backends.sqlite3', ...

Then wedge the test runner methods that were destroying and rebuilding
the database:


def setup_databases(self, **kwargs):
from django.db import connections
old_names = []
mirrors = []
for alias in connections:
connection = connections[alias]
# If the database is a test mirror, redirect it's connection
# instead of creating a test database.
if connection.settings_dict['TEST_MIRROR']:
mirrors.append((alias, connection))
mirror_alias = connection.settings_dict['TEST_MIRROR']
connections._connections[alias] =
connections[mirror_alias]
else:
old_names.append((connection,
connection.settings_dict['NAME']))
#connection.creation.create_test_db(self.verbosity,
autoclobber=not self.interactive)
return old_names, mirrors

def teardown_databases(self, old_config, **kwargs):
from django.db import connections
old_names, mirrors = old_config
# Point all the mirrors back to the originals
for alias, connection in mirrors:
connections._connections[alias] = connection
# Destroy all the non-mirror databases
#for connection, old_name in old_names:
#connection.creation.destroy_test_db(old_name, self.verbosity)

from django.test.simple import DjangoTestSuiteRunner

DjangoTestSuiteRunner.setup_databases = setup_databases
DjangoTestSuiteRunner.teardown_databases = teardown_databases

The next thing I'll need to do is rebuild the database only if the
models or .json files change.

I could add that to the wedge methods, above, or I could simply add a
"make" like system to the fabric fabfile.py that runs the test:

def test():
#  TODO  Check file time of test_myapp.db. If it's less than
my_app/models.py
   # or my_app/fixtures/my_app_database.json, rebuild the
db file

_sh('python manage.py test --settings=test_settings my_app --
verbosity=0')

This system now fully exploits sqlite3, especially its ability to
treat a transaction as a virtual ":memory:" database. It does not even
change the file time on the .db file when the tests run.

Could someone better at Django internals than me package this system
up and contrib it?

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand

-- 
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.

how to get the test runner to only rebuild & populate the test_database if it changed?

[Phlip]

Djangoists:

Me again. Still helping clients TDD despite obese databases.

Right now the test suite takes a minute to build a database with >20
models (and lots of fields in each one), then load a mere 7,000
records. Yes I will cut down on the records, but building the
database, in sqlite3 :memory: mode, is also a big chunk.

So if I built the DB once, then ran a TDD cycle, couldn't the entire
system leave the database in a sqlite3 document, and put transactions
around each test case?

I'm going to copy the TestCase classes into our project, and have my
way with them. But is there an easier way, or has someone already done
this?

(1.2, BTW - the obese database prevents an upgrade to Django 1.3!)

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand

-- 
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.

Re: Can't Test Apps Without Models?

[Maksymus007]

just create empty models,py file in your app folder. I don't know why,but
thats how Django 'sees' your applications.

Pozdrawiam, Maksymilian Pawlak
09-05-2011 23:58 użytkownik "protonpopsicle" <smeisbur...@gmail.com>
napisał:
> Is this a bug?
>
> If I run my unittest with './manage.py test myapp' and myapp does not
> contain a models.py file, the following error results:
>
> django.core.exceptions.ImproperlyConfigured: App with label fogbugz
> could not be found
>
> This error does not describe the problem. Also, shouldn't one be able
> to run tests on apps without models?
>
> --
> 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.

Re: Can't Test Apps Without Models?

[Boštjan Mejak]

You must create a tests.py file in your project's directory. Have your tests
in that file. I am not sure on that one, but try.

-- 
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.

Can't Test Apps Without Models?

[protonpopsicle]

Is this a bug?

If I run my unittest with './manage.py test myapp' and myapp does not
contain a models.py file, the following error results:

django.core.exceptions.ImproperlyConfigured: App with label fogbugz
could not be found

This error does not describe the problem. Also, shouldn't one be able
to run tests on apps without models?

-- 
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.

Re: can't create test (secondary) database

[Javier Guerra Giraldez]

On Fri, Apr 29, 2011 at 1:16 PM, Shawn Milochik <sh...@milochik.com> wrote:
> This doesn't help if the same host is being used, but you can get around
> this by creating a second settings file and using it during your tests.

thanks, i forgot that option.

i'm using that to override the engine of the oracle database, turning
to SQLite during test.  unfortunately, since my legacy models have a
managed=False setting, they're not created in the test database.

for now, i added some preparation code that overrides that setting, to
ensure that all the tables are created for testing.  it's _very_ ugly,
but not much worse than some mocking code i've seen.

-- 
Javier

-- 
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.

Re: Best way to tell if we're in a test

[Jody McIntyre]

This is fine as a general principle, but here we're dealing with middleware
that affects every other application.  It's not a good idea to require other
applications to change all their tests to mock out functionality in a module
they've just added, plus that would be a lot of work.  You'd have to use it
every time you run self.client.login() or post to the login URL in a test
case.  That's probably why django-digest and django-bcrypt disable
themselves under test (by default) and why I'd like to do it for security
questions.

Cheers,
Jody

On Fri, Apr 29, 2011 at 2:03 PM, Chris Czub <chris.c...@gmail.com> wrote:

> I think you might be taking the wrong approach. Rather than having your
> application code checking whether or not it's in a test, have your testing
> code disable/mock certain behaviors that you don't want exercised(like have
> it always return that the user answered the security question correctly or
> something).
>
> Python's dynamic nature makes it easy to monkey patch things like this.
> Look at the Mock class: http://python-mock.sourceforge.net/
>
>
> On Fri, Apr 29, 2011 at 12:53 PM, Jody McIntyre <jo...@trustcentric.com>wrote:
>
>> What's the best way to tell (from regular code) if we're in a test?  I
>> have added extra authentication steps (security questions) that would be
>> difficult to deal with in tests where you just want to run
>> self.client.login() or post to the login URL.  I've noticed that several
>> third party modules, such as django-digest and django-bcrypt, also disable
>> parts of their functionality during testing like this:
>>
>> from django.core import mail
>>
>> if hasattr(mail, 'outbox'):
>> # we are under a test
>> else:
>> # not under a test
>>
>> This works, but it's an undocumented side effect so I'm worried it might
>> change in a future version.  What's the correct way to tell if we're in a
>> test?
>>
>> Thanks,
>> Jody
>>
>> --
>> 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.

Re: can't create test (secondary) database

[Shawn Milochik]

You can specify the test database info (db, name, and password) for each 
database defined in settings, if you're using 1.2 or greater.


http://docs.djangoproject.com/en/1.3/ref/settings/#databases

This doesn't help if the same host is being used, but you can get around 
this by creating a second settings file and using it during your tests.


In your second settings file, (let's call it test_settings.py), you 
would only import the main settings and then override what you have to.


from settings import *

DATABASES['your_oracle_db'] = {'host': 'new_host', 'port': 1234}

Then run your tests by passing --settings=test_settings instead of using 
the default.


Be careful not to change too much in your alternate settings file or you 
run the risk of testing something too different than your real setup and 
missing a flaw.


Shawn


--
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.

can't create test (secondary) database

[Javier Guerra Giraldez]

Hi All,

for the first time, i'm using multiple databases.  specifically, i
have 'my' data in a MySQL db (set as 'default') but also need to get
some extra info from a proprietary system with it's own Oracle DB, for
this i got a user/password with read/only privileges (only SELECT and
friends).  Of course, when i want to run the tests, i get an "error
creating the test database: ORA-01031: insufficient privileges"
message.

i guess any of these (in decreasing order of preference) would be a
solution, but i don't know how to do any of them.  (well, maybe the
last one could be done via some creative use of
development/test/deployment patching)

1: use the 'real' db.  since the user is read/only, i can't mess it
up.  i can't install test fixtures either, but there's lots of old
records that are static enough for my tests.

2: create both test DBs in the MySQL server.  of course, the SQL
semantics aren't the same; but i'm using _very_ simple queries to get
that foreign data.

3: create the test DB in another oracle server.  i guess that's the
simplest advice, but also the one i hope to avoid.

any advices?


-- 
Javier

-- 
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.

Re: Best way to tell if we're in a test

[Chris Czub]

I think you might be taking the wrong approach. Rather than having your
application code checking whether or not it's in a test, have your testing
code disable/mock certain behaviors that you don't want exercised(like have
it always return that the user answered the security question correctly or
something).

Python's dynamic nature makes it easy to monkey patch things like this. Look
at the Mock class: http://python-mock.sourceforge.net/

On Fri, Apr 29, 2011 at 12:53 PM, Jody McIntyre <jo...@trustcentric.com>wrote:

> What's the best way to tell (from regular code) if we're in a test?  I have
> added extra authentication steps (security questions) that would be
> difficult to deal with in tests where you just want to run
> self.client.login() or post to the login URL.  I've noticed that several
> third party modules, such as django-digest and django-bcrypt, also disable
> parts of their functionality during testing like this:
>
> from django.core import mail
>
> if hasattr(mail, 'outbox'):
> # we are under a test
> else:
> # not under a test
>
> This works, but it's an undocumented side effect so I'm worried it might
> change in a future version.  What's the correct way to tell if we're in a
> test?
>
> Thanks,
> Jody
>
> --
> 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.

Best way to tell if we're in a test

[Jody McIntyre]

What's the best way to tell (from regular code) if we're in a test?  I have 
added extra authentication steps (security questions) that would be 
difficult to deal with in tests where you just want to run 
self.client.login() or post to the login URL.  I've noticed that several 
third party modules, such as django-digest and django-bcrypt, also disable 
parts of their functionality during testing like this:

from django.core import mail

if hasattr(mail, 'outbox'):
# we are under a test
else:
# not under a test

This works, but it's an undocumented side effect so I'm worried it might 
change in a future version.  What's the correct way to tell if we're in a 
test?

Thanks,
Jody

-- 
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.

Re: authentication not working using test client

[Roy Smith]

I figured it out.  When I first set up my settings.py file, I did:

AUTHENTICATION_BACKENDS = (
'socialregistration.auth.FacebookAuth',
)

which breaks (well, omits) the default authentication module that 
client.login() depends on.  I needed to do:

AUTHENTICATION_BACKENDS = (
'django.contrib.auth.backends.ModelBackend',
'socialregistration.auth.FacebookAuth',
)


On Apr 26, 2011, at 12:56 PM, Roy Smith wrote:

> I've got a test case that essentially looks like this:
> 
> --
> from django.test import TestCase
> from django.test.client import Client
> from django.contrib.auth.models import User
> 
> class ApiTest(TestCase):
>def test_login(self):
>username = 'foo'
>email = 'f...@example.com'
>password = 'secret'
>user = User.objects.create_user(username, mail,
> password=password)
>assert user.username == username
>assert user.is_active
>client = Client()
>assert client.login(username=username, password=password)  #
> this assertion fails
> --
> 
> When I run it, the client.login() assertion fails.  Any idea what I
> might be doing wrong?
> 
> -- 
> 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.
> 


---
Roy Smith
r...@panix.com





-- 
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.

authentication not working using test client

[Roy Smith]

I've got a test case that essentially looks like this:

--
from django.test import TestCase
from django.test.client import Client
from django.contrib.auth.models import User

class ApiTest(TestCase):
def test_login(self):
username = 'foo'
email = 'f...@example.com'
password = 'secret'
user = User.objects.create_user(username, mail,
password=password)
assert user.username == username
assert user.is_active
client = Client()
assert client.login(username=username, password=password)  #
this assertion fails
--

When I run it, the client.login() assertion fails.  Any idea what I
might be doing wrong?

-- 
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.

Models within Imported TestCases not created in Test Database...

[Bob Carr]

Hi All,

Why don't models within tests imported into app/tests.py get picked up
during test database creation.

from django.db import models
from django.test import TestCase

# This test defined in app/tests.py works fine...
class test_TestModel(TestCase):

  class TestModel(models.Model):
name = models.CharField(max_length=200)

  def test___init__(self):
test = self.TestModel(name='Test')
test.save()
self.failUnless(test and test.pk)

# Importing a test that is equivalent to the test above into app/
tests.py...
# DatabaseError: relation "testimported_testmodel" does not exist
# LINE 1: INSERT INTO "testimported_testmodel" ("name") VALUES
(E'Test...
from testimported.tests import test_TestImportedModel


The only ticked I can find that is related to this issue is:
http://code.djangoproject.com/ticket/7835 but there is no discussion
of imported tests.

Thanks!!!

-- 
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.

Re: How to unit test if user has access to page

[Pedro Kroger]

Good point. Thank you guys!

Pedro

On Sat, Apr 16, 2011 at 2:15 PM, Martin Brochhaus
<martin.brochh...@googlemail.com> wrote:
> Also beware! Only do a client.post if you really want to test that a user
> submits a form. Usually when a not-logged-in-user wants to go to a secured
> page immediately he will try a get request and just enter the URL. Sometimes
> your view behaves differently on get and on post (most of the times) so you
> probably should test both scenarios.
> Best regards,
> Martin
>
> --
> 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.
>



-- 
http://pedrokroger.net

-- 
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.

Re: Test fails to run

[gladys]

Hi,

In which part of the test are you truncating the db?
It could also be that test_ db is still in your database
after a previous run of test, and it refuses to flush.
Try manually deleting it and running syncdb again.


--
Gladys
http://blog.bixly.com


On Apr 17, 1:20 am, Aleksandr Vladimirskiy <sa...@theotheralex.com>
wrote:
> Hello,
>
> I'm running a test but it fails after syncdb part with the following
> message:
>
> Error: Database test_ couldn't be flushed. Possible
> reasons:
>   * The database isn't running or isn't configured correctly.
>   * At least one of the expected database tables doesn't exist.
>   * The SQL was invalid.
> Hint: Look at the output of 'django-admin.py sqlflush'. That's the SQL
> this command wasn't able to run.
> The full error: cannot truncate a table referenced in a foreign key
> constraint
> DETAIL:  Table "" references "".
> HINT:  Truncate table "" at the same time, or use
> TRUNCATE ... CASCADE.
>
> The foreign key is between models in 2 different apps.
>
> Thanks,
>
> Alex

-- 
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.

Test fails to run

[Aleksandr Vladimirskiy]

Hello,

I'm running a test but it fails after syncdb part with the following
message:

Error: Database test_ couldn't be flushed. Possible
reasons:
  * The database isn't running or isn't configured correctly.
  * At least one of the expected database tables doesn't exist.
  * The SQL was invalid.
Hint: Look at the output of 'django-admin.py sqlflush'. That's the SQL
this command wasn't able to run.
The full error: cannot truncate a table referenced in a foreign key
constraint
DETAIL:  Table "" references "".
HINT:  Truncate table "" at the same time, or use
TRUNCATE ... CASCADE.

The foreign key is between models in 2 different apps.

Thanks,

Alex

-- 
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.

Aw: How to unit test if user has access to page

[Martin Brochhaus]

Also beware! Only do a client.post if you really want to test that a user 
submits a form. Usually when a not-logged-in-user wants to go to a secured 
page immediately he will try a get request and just enter the URL. Sometimes 
your view behaves differently on get and on post (most of the times) so you 
probably should test both scenarios.

Best regards,
Martin

-- 
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.

Re: How to unit test if user has access to page

[Javier Guerra Giraldez]

On Fri, Apr 15, 2011 at 8:54 PM, Pedro Kroger <pedro.kro...@gmail.com> wrote:
> result = self.client.post('/dashboard/')
>
> But I don't know how to test if the result is the dashboard or the
> login page. Could you guys point me in the right direction?

from the docs 
(http://docs.djangoproject.com/en/1.3/topics/testing/#django.test.TestCase.assertRedirects):

result = self.client.post('/dashboard/')
self.assertRedirects(result, '/login/')

-- 
Javier

-- 
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.

How to unit test if user has access to page

[Pedro Kroger]

Hi,

I writing some unit tests and I'd like to test if an unlogged user has
access to the main dashboard page.
In my application, if the user is logged it will go to the dashboard,
if it isn't, it will go to the login page.
I know how to get to the webpage:

result = self.client.post('/dashboard/')

But I don't know how to test if the result is the dashboard or the
login page. Could you guys point me in the right direction?

Thanks,

Pedro

-- 
http://pedrokroger.net

-- 
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.

Re: Unit test successful in isolation, fails when the whole app is tested

[Evgeny]

Thanks, Karen.

The specifics are:
* when the test is run as
  "python manage.py test askbot"
   - all tests from this suite fail (there are two, only one shown for
brevity)
   and the remaining 400 or so tests pass
* the nature of failure - there are 0 email in the outbox (with one
expected)
* when the tests are run as
  "python manage.py test
askbot.TagFollowedInstantWholeForumEmailAlertTests"
  tests pass.

So there must be something in the previous tests
or the application code they ran before...

Another thing - I use celery to send emails and have setting
CELERY_ALWAYS_EAGER = True, as recommended for the testing purposes.






On Apr 8, 3:47 am, Karen Tracey <kmtra...@gmail.com> wrote:
> On Thu, Apr 7, 2011 at 11:21 PM, Evgeny <evgeny.fad...@gmail.com> wrote:
>
> > I have one test suite (among many others) in my application that
> > succeeds in isolation, but fails
> > when I run the whole battery. Could anyone suggest where to start
> > looking?
>
> Start with the specifics of the failure, look at the previously run tests
> and see what they may have done that could cause the failure. I don't think,
> for example, that the email outbox is reset between test methods (which
> strikes me as a bit odd at the moment, I'm not sure why that is not reset
> for each test run...perhaps I'm wrong about it not being reset or there is a
> good reason that escapes me at the moment). Anyway I think your assertions
> that are testing for a specific number of emails in the box could fail if a
> previous test caused email to be sent also. But you haven't said what the
> specifics of the failure are so I'm not sure that is what you are seeing.
>
> Karen
> --http://tracey.org/kmt/

-- 
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.

Re: Unit test successful in isolation, fails when the whole app is tested

[Karen Tracey]

On Thu, Apr 7, 2011 at 11:21 PM, Evgeny <evgeny.fad...@gmail.com> wrote:

>
> I have one test suite (among many others) in my application that
> succeeds in isolation, but fails
> when I run the whole battery. Could anyone suggest where to start
> looking?


Start with the specifics of the failure, look at the previously run tests
and see what they may have done that could cause the failure. I don't think,
for example, that the email outbox is reset between test methods (which
strikes me as a bit odd at the moment, I'm not sure why that is not reset
for each test run...perhaps I'm wrong about it not being reset or there is a
good reason that escapes me at the moment). Anyway I think your assertions
that are testing for a specific number of emails in the box could fail if a
previous test caused email to be sent also. But you haven't said what the
specifics of the failure are so I'm not sure that is what you are seeing.

Karen
-- 
http://tracey.org/kmt/

-- 
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.

Unit test successful in isolation, fails when the whole app is tested

[Evgeny]

Hello,

I have one test suite (among many others) in my application that
succeeds in isolation, but fails
when I run the whole battery. Could anyone suggest where to start
looking? Thanks.

Posting the code below. The test is counting number of emails sent as
a result of posting a question
at the forum. The emails are send by a Celery task (with
CELERY_ALWAYS_EAGER = True).

class
TagFollowedInstantWholeForumEmailAlertTests(utils.AskbotTestCase):
def setUp(self):
self.create_user(
username = 'user1',
notification_schedule = {'q_all': 'i'},
status = 'm'
)
self.create_user(
username = 'user2',
status = 'm'
)

def test_wildcard_catches_new_tag(self):
"""users asks a question with a brand new tag
and other user subscribes to it by wildcard
"""
askbot_settings.update('USE_WILDCARD_TAGS', True)
self.user1.email_tag_filter_strategy =
const.INCLUDE_INTERESTING
self.user1.save()
self.user1.mark_tags(
wildcards = ('some*',),
reason = 'good',
action = 'add'
)
self.user2.post_question(
title = 'some title',
body_text = 'some text for the question',
tags = 'something'
)
outbox = django.core.mail.outbox
self.assertEqual(len(outbox), 1)
self.assertEqual(len(outbox[0].recipients()), 1)
self.assertTrue(
self.user1.email in outbox[0].recipients()
)

-- 
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.

Issues with post_save signals on test execution?

[rikuthero...@gmail.com]

Hi,

After migrate an application from Django 1.1 to Django 1.3 I noticed that
some unittest was failing. Debugging I get to the point that the post_save
functions didn't execute on test running. If I see the receivers on the test
execution:

ipdb> from django.db.models import signals
ipdb> signals.post_save.receivers
[]

But, seeing it on a ./manage.py shell:

In [4]: signals.post_save.receivers
Out[4]:
[((148050580, 135782264),
  ),
 ((148158980, 148372636),
  ),
 (((14908, 149046916), 148893804),
  BoundMethodWeakref( ._rename_resize_image )),
 (((150046508, 147356780), 150265060),
  BoundMethodWeakref( ._save )),
 (((150338604, 149046916), 150285820),


And a lot more... I check that the post_save signal is registering properly
on the test execution, but when you access to it, is empty.

Any ideas?

Thanks in advance

-- 
Pablo Recio Quijano

Desarrollador Django
Yaco Sistemas - http://www.yaco.es/

-- 
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.

Re: my assertRases test does not call the clean() method

[Kenneth Gonsalves]

On Thu, 2011-03-17 at 03:26 -0700, Daniel Roseman wrote:
> >
> This has nothing to do with the use of assertRaises. Creating a model 
> programmatically does *not* call clean(), as clearly specified in the 
> documentation 
> (http://docs.djangoproject.com/en/1.2/ref/validators/#how-validators-are-run):
>  
> "Note that validators will not be run automatically when you save a
> model".
> 
> In order to test model validation, you should create the model
> instance and 
> then call instance.full_clean() on it. 

thanks - works now.
-- 
regards
KG
http://lawgon.livejournal.com
Coimbatore LUG rox
http://ilugcbe.techstud.org/

-- 
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.

Re: my assertRases test does not call the clean() method

[Daniel Roseman]

On Thursday, March 17, 2011 9:47:50 AM UTC, lawgon wrote:
>
> hi,
>
> I have a test like this:
>
>
> self.assertRaises(ValidationError,Costtocompany.objects.create,profile=self.profile1,
> company_laptop = True,
> ctc_pa=1,
> ctc_pm =1,
> laptop_sno = '',
> datefrom = self.dfrom)
>
> this model has a clean() method that works when I save from admin, but
> is not called when I run the test:
>
> def clean(self):
> """
> if laptop then sno otherwise no sno. If if company_car -
> make and regno
> """
> 
> if self.company_laptop == True:
> if self.laptop_sno == '':
> raise ValidationError(_("Fill in laptop serial number"))
>
> the message I get from the test is:
>
> Traceback (most recent call last):
>   File "/home/lawgon/servicefirst/employee/tests.py", line 42, in
> testCosttocompanyvalidation
> datefrom = self.dfrom)
> AssertionError: ValidationError not raised
>
> any clues?
> -- 
> regards
> KG
>
This has nothing to do with the use of assertRaises. Creating a model 
programmatically does *not* call clean(), as clearly specified in the 
documentation 
(http://docs.djangoproject.com/en/1.2/ref/validators/#how-validators-are-run): 
"Note that validators will not be run automatically when you save a model".

In order to test model validation, you should create the model instance and 
then call instance.full_clean() on it.
--
DR.

-- 
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.

my assertRases test does not call the clean() method

[Kenneth Gonsalves]

hi,

I have a test like this:

self.assertRaises(ValidationError,Costtocompany.objects.create,profile=self.profile1,
company_laptop = True,
ctc_pa=1,
ctc_pm =1,
laptop_sno = '',
datefrom = self.dfrom)

this model has a clean() method that works when I save from admin, but
is not called when I run the test:

def clean(self):
"""
if laptop then sno otherwise no sno. If if company_car -
make and regno
"""

if self.company_laptop == True:
if self.laptop_sno == '':
raise ValidationError(_("Fill in laptop serial number"))

the message I get from the test is:

Traceback (most recent call last):
  File "/home/lawgon/servicefirst/employee/tests.py", line 42, in
testCosttocompanyvalidation
datefrom = self.dfrom)
AssertionError: ValidationError not raised

any clues?
-- 
regards
KG
http://lawgon.livejournal.com
Coimbatore LUG rox
http://ilugcbe.techstud.org/

-- 
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.

Tests with test specific models

[Mike Ramirez]

Example: 

I have an app that uses ContentType and I want to test that against an 
arbitrary model to make sure that the usage of ContentType is correct.


Ex:

In my app.models I have:

class Rating(models.Model): 
  total = models.DecimalField(default=0, decimal_places=2, max_digits=8)
  score = models.DecimalField(default=decimal.Decimal('0.00'), 
decimal_places=2, max_digits=6)
  votes = models.IntegerField(max_length=6, default=0, blank=True)

class RatedItem(models.Model):
  user = models.ForeignKey(User, related_name="RatedItem_User")
  content_type = models.ForeignKey(ContentType, related_name="RatedItem")
  object_id = models.PositiveIntegerField()
  item = generic.GenericForeignKey('content_type', 'object_id')


RatedItem is used to check if the user has rated an item already. For testing, 
I would like to have something like:

class TestItem(models.Model):
  name = models.CharField(max_length=20)
  rating = models.ForeignKey(Rating)

I don't want to clutter up my apps model.py with testing only stuff, that 
might confuse/encourage devs to do the wrong thing.

django-tagging gives the example, have a tests directory in your app, with 
__init__.py, tests.py , models.py, a settings.py with db info and an installed 
apps settings, that has only django.contrib.contentypes, tagging and 
tagging.tests.  OK I get this is the setup (mostly, the env variables in 
settings.py are rather annoying, but understandable). but two things about 
this bother me. 

A. How do the tests know to look for this setup and use the settings/model 
supplied?

B. Where is it documented?  (B. is the more important question)

I think way back something about this was mentioned on the list a long time 
ago. I rememeber a letter about tests/ or tests.py in apps. I just don't 
remember any information given on how to setup the testing environment this 
way, as it's own standalone app.

Also for south users/devs, how well does south cope with this situtaion?



Mike
-- 
Tcl tends to get ported to weird places like routers.
 -- Larry Wall in <199710071721.kaa19...@wall.org>

-- 
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.

Re: How do I run test and get results programmatically? (django, south, fixtures, sqlite)

[Jumpfroggy]

@gladys,

While that didn't solve my original question, it did solve another
related problem.  Before, I had issue with migrations failing since
they depended on pre-existing data (which did not exist in the blank
testing database).  But if I added an initial_data.json fixture, it
gets run for every migration - during prod and testing.  This is bad.

So I went with "SOUTH_TESTS_MIGRATE = False", then I manually load the
"test_data" fixture during the first test.  Works great.

I still can't figure out why running "python manage.py test" and
running the above code have such different results.  I'd love to
figure out why, since it would be easier to use the API calls and look
in the "failures" var than it is to run the "python manage.py test"
command and parse through the output.  But for now, the latter gets
things working.

So thanks!  My original question is still open, but I'm un-stuck and
can continue working for now.

-- 
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.

Re: test cannot find assertContains

[Mike Ramirez]

On Sunday, March 13, 2011 10:58:10 pm Kenneth Gonsalves wrote:
> On Sun, 2011-03-13 at 22:40 -0700, Mike Ramirez wrote:
> > > I know it is there - but it is half way down the page. My point is
> > 
> > that
> > 
> > > it should be at the top of the page. For what it's worth I filed a
> > > ticket.
> > 
> > I've een wondering about this myself, but I'm not sure that it's in
> > the wrong
> > place, but it's not in the perfect place.
> 
> all I am doing is giving the devs feedback from a dumb user ;-) The docs
> have evolved historically, but now and then maybe a restructuring has to
> be done - and some times the restructuring doesn't help. For example the
> internationalisation docs have now been split into i18n and l10n
> sections. This causes some confusion as most people are not clear about
> the difference between these two.


As I was writing that I was wondering if I should have done that in your bug 
report. I just linked my message to it.

Mike
-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things.
-- Doug Gwyn

-- 
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.

Re: test cannot find assertContains

[Mike Ramirez]

On Sunday, March 13, 2011 10:40:51 pm you wrote:
> With this all in mind, I think they do enough to say use 'django.testing',
> without having it specifically marked at the start.
> 
> But it could possibly benefit from being two pages, one an "overview" and
> one page for "django.testing"
> 
> 
> Mike

err... s/django.testing/django.test/g

Mike
-- 
"The trouble with doing something right the first time is that nobody 
appreciates how difficult it was."
-- Walt West

-- 
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.

Re: test cannot find assertContains

[Kenneth Gonsalves]

On Sun, 2011-03-13 at 22:40 -0700, Mike Ramirez wrote:
> > I know it is there - but it is half way down the page. My point is
> that
> > it should be at the top of the page. For what it's worth I filed a
> > ticket.
> 
> I've een wondering about this myself, but I'm not sure that it's in
> the wrong 
> place, but it's not in the perfect place. 

all I am doing is giving the devs feedback from a dumb user ;-) The docs
have evolved historically, but now and then maybe a restructuring has to
be done - and some times the restructuring doesn't help. For example the
internationalisation docs have now been split into i18n and l10n
sections. This causes some confusion as most people are not clear about
the difference between these two. 
-- 
regards
KG
http://lawgon.livejournal.com
Coimbatore LUG rox
http://ilugcbe.techstud.org/

-- 
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.

Re: test cannot find assertContains

[Mike Ramirez]

On Sunday, March 13, 2011 09:58:18 pm Kenneth Gonsalves wrote:
> On Sat, 2011-03-12 at 00:12 -0800, Mike Ramirez wrote:
> > On Friday, March 11, 2011 11:37:38 pm Kenneth Gonsalves wrote:
> > > and all is well. I think the dev docs need to be clearer on this
> > 
> > point
> > 
> > > and mention this at the outset. After all they *are* dev docs.
> > 
> > http://docs.djangoproject.com/en/1.2/topics/testing/#testcase
> 
> I know it is there - but it is half way down the page. My point is that
> it should be at the top of the page. For what it's worth I filed a
> ticket.

I've een wondering about this myself, but I'm not sure that it's in the wrong 
place, but it's not in the perfect place.

 IMO, it's in its natural place if you apply how the other docs are split up. 
Testing is a single page and doesn't benefit from the seperation say something 
like forms gets. This is where the problem probably lies.

If you look at the forms api, it describes the basic forms api with just 
forms.Form, and goes into how to use the forms, later on you run into 
forms.ModelForm in it's own page. All of this depends on prior knowledge and 
steps down in a logical pattern i.e. forms, fields, widgets. 

Testing works the same way, introducing the basic unit testing functionality, 
including how to build simple tests. Then works through running them. I think 
it's natural to stop reading there, but we are intended to continue on down 
through the whole page as it builds on itself, like the rest of the docs.

Also starting with unittest shows that we can use unittest as we need (in a 
non django lib, for example a img lib for handling all the image 
resizes/changes we may want. this wouldn't require any django related tests. 
There is no questioning the if testrunner will question these. Also ending 
with testing.TestCase leaves that fresher in our minds as it's the last thing 
we read (theoretically).  

ftr, in atleast 1.2.3 forward startapp generates a tests.py with this code:

[gmike@priss keis]$ cat newfun/tests.py 
"""
This file demonstrates writing tests using the unittest module. These will 
pass
when you run "manage.py test".

Replace this with more appropriate tests for your application.
"""

from django.test import TestCase


class SimpleTest(TestCase):
def test_basic_addition(self):
"""
Tests that 1 + 1 always equals 2.
"""
self.assertEqual(1 + 1, 2)


*note: 1.2.3 also has docstring tests included as part of the sample/exmaple.

With this all in mind, I think they do enough to say use 'django.testing', 
without having it specifically marked at the start.

But it could possibly benefit from being two pages, one an "overview" and one 
page for "django.testing"


Mike

-- 
solar flares

-- 
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.

Re: test cannot find assertContains

[Kenneth Gonsalves]

On Sat, 2011-03-12 at 00:12 -0800, Mike Ramirez wrote:
> On Friday, March 11, 2011 11:37:38 pm Kenneth Gonsalves wrote:
> 
> > and all is well. I think the dev docs need to be clearer on this
> point
> > and mention this at the outset. After all they *are* dev docs.
> 
> http://docs.djangoproject.com/en/1.2/topics/testing/#testcase  

I know it is there - but it is half way down the page. My point is that
it should be at the top of the page. For what it's worth I filed a
ticket.
-- 
regards
KG
http://lawgon.livejournal.com
Coimbatore LUG rox
http://ilugcbe.techstud.org/

-- 
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.

Re: How do I run test and get results programmatically? (django, south, fixtures, sqlite)

[gladys]

I'm not sure if this is what you need, but if the problem is with the
migrations not being run, you can specify a setting in your
settings.py to use syncdb when running tests.

#settings.py
SOUTH_TESTS_MIGRATE = False # make test database created using syncdb
rather than migrations

Goodluck.

--
Gladys
http://bixly.com


On Mar 12, 5:32 am, Jumpfroggy <rocketmonk...@gmail.com> wrote:
> I have an app that I'm starting to write tests for.  The app uses
> south for all migrations and mysql for the db.
>
> I wrote some tests and also created an initial_data.json fixture to
> provide some default data.  If I run "python manage.py test", the
> database is created via sqlite, the tests are run, and then the report
> is spit out.  This works fine.
>
> However, I want to automate this where I can programmatically run
> tests, find the failures, and do some custom logging/saving of the
> failures.  How do I run the tests in python?
>
> I've tried a few variations of the below code, but the problem is the
> database.  When I run the "python manage.py test" command, it
> automatically uses sqlite3 as the backend, creates the database, and
> uses it for all tests.  However, when I run my own tests, it uses the
> mysql backend.  If I force it to use sqlite, is has problems with the
> fixtures because the migrations are not run before installing the
> fixtures.
>
> How do I run tests manually using the same database setup that happens
> when using the manage.py test command?
>
> My code:
>
>     import my_application.settings
>
>     # NOTE: Use this to force the testing database to use the sqlite
> engine.
>     my_application.settings.DATABASE_ENGINE = 'sqlite3'
>
>     from django.core.management import setup_environ
>     setup_environ(my_application.settings)
>
>     from django.conf import settings
>     from django.test.utils import get_runner
>
>     verbosity = 1
>     interactive = False
>     failfast = True
>     TestRunner = get_runner(settings)
>
>     test_labels = ()
>
>     test_runner = TestRunner(verbosity=verbosity,
> interactive=interactive, failfast=failfast)
>     failures = test_runner.run_tests(test_labels)
>
> And this is the error I get:
>
>     calling TestRunner.run_tests()
>       verbosity: 1
>       interactive: False
>       failfast: True
>       test_labels: ()
>     connection.settings_dict: {'ENGINE': 'django.db.backends.sqlite3',
> 'TEST_MIRROR': None, 'NAME': 'my_application', 'TEST_CHARSET': None,
> 'TIME_ZONE': 'America/New_York', 'TEST_COLLATION': None, 'OPTIONS':
> {}, 'HOST': '', 'USER': 'my_application', 'TEST_NAME': None,
> 'PASSWORD': 'my_application', 'PORT': ''}
>     test_databases: {('', '', 'django.db.backends.sqlite3',
> 'my_application'): ['default']}
>     Creating test database 'default'...
>     Syncing...
>     Creating table django_admin_log
>     Creating table auth_permission
>     Creating table auth_group_permissions
>     Creating table auth_group
>     Creating table auth_user_user_permissions
>     Creating table auth_user_groups
>     Creating table auth_user
>     Creating table auth_message
>     Creating table django_content_type
>     Creating table django_session
>     Creating table django_site
>     Creating table south_migrationhistory
>     Installing index for admin.LogEntry model
>     Installing index for auth.Permission model
>     Installing index for auth.Group_permissions model
>     Installing index for auth.User_user_permissions model
>     Installing index for auth.User_groups model
>     Installing index for auth.Message model
>     No fixtures found.
>
>     Synced:
>      > django.contrib.admin
>      > django.contrib.auth
>      > django.contrib.contenttypes
>      > django.contrib.sessions
>      > django.contrib.sites
>      > south
>
>     Not synced (use migrations):
>      - my_application
>     (use ./manage.py migrate to migrate these)
>     test_db_name: ':memory:'
>     Problem installing fixture 'C:\virtualenv-my_application\lib
> \site-packages\django\contrib\auth\fixtures\authtestdata.json':
> Traceback (most recent call last):
>       File "C:\virtualenv-my_application\lib\site-packages\django\core
> \management\commands\loaddata.py", line 174, in handle
>         obj.save(using=using)
>       File "C:\virtualenv-my_application\Lib\site-packages\django\core
> \serializers\base.py", line 165, in save
>         models.Model.save_base(self.object, using=using, raw=True)
>       File "C:\virtualenv-my_application\Lib\site-packages\django\db
> \models\base.py", line 566, in save_base
>         created=(not record_exists), 

Re: test cannot find assertContains

[werefr0g]

Hi,

As far I can tell from the documentation, to use Django's extended 
TestCase, you should use django.test.TestCase [1]. Using 
django.utils.unittest allows you to benefit from python 2.7 unittest2 
library, [2]


Regards,

[1] 
http://docs.djangoproject.com/en/dev/topics/testing/#django.test.TestCase

[2] http://docs.djangoproject.com/en/dev/topics/testing/#writing-unit-tests

--
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.

Re: test cannot find assertContains

[Mike Ramirez]

On Friday, March 11, 2011 11:37:38 pm Kenneth Gonsalves wrote:

> and all is well. I think the dev docs need to be clearer on this point
> and mention this at the outset. After all they *are* dev docs.

http://docs.djangoproject.com/en/1.2/topics/testing/#testcase 


Mike
--
Would that my hand were as swift as my tongue.
-- Alfieri

-- 
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.

Re: test cannot find assertContains

[Kenneth Gonsalves]

On Fri, 2011-03-11 at 23:23 -0800, Mike Ramirez wrote:
> On Friday, March 11, 2011 11:21:02 pm you wrote:
> > The problem here is that assertContains is not part of
> unittest/unittest2.
> > 
> > It's defined in TransactionTestCase in django.test, which extends
> > unittest2.TestCase and adds in assertContains, assertNotContains,
> > assetFormError, basically django specific assertions.
> > 
> > 
> > Mike
> 
> Sorry faster trigger finger tonight.  But I want to add, I think we're
> meant 
> to use the stuff in django.test for our tests. 

*now* I understand. I replaced 

from django.utils import unittest
with
from django.test import TestCase

and all is well. I think the dev docs need to be clearer on this point
and mention this at the outset. After all they *are* dev docs.
-- 
regards
KG
http://lawgon.livejournal.com
Coimbatore LUG rox
http://ilugcbe.techstud.org/

-- 
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.

Re: test cannot find assertContains

[Mike Ramirez]

On Friday, March 11, 2011 11:21:02 pm you wrote:
> The problem here is that assertContains is not part of unittest/unittest2.
> 
> It's defined in TransactionTestCase in django.test, which extends
> unittest2.TestCase and adds in assertContains, assertNotContains,
> assetFormError, basically django specific assertions.
> 
> 
> Mike

Sorry faster trigger finger tonight.  But I want to add, I think we're meant 
to use the stuff in django.test for our tests. 

Mike
-- 
The worst sin towards our fellow creatures is not to hate them,
but to be indifferent to them; that's the essence of inhumanity.
-- G.B. Shaw

-- 
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.

Re: test cannot find assertContains

[Mike Ramirez]

On Friday, March 11, 2011 11:11:21 pm Kenneth Gonsalves wrote:
> On Fri, 2011-03-11 at 23:04 -0800, Mike Ramirez wrote:
> > > from django.utils import unittest
> > 
> > from django.test import TestCase
> > 
> > the stuff in utils.unittest is unittest2 stuff if you're using python
> > <2.7
> > (unittest2 is part of 2.7 now as unittest).
> 
> I am using 2.6, but according to the django docs, django has a bundled
> version of unittest2 which is accessed from django.utils.unittest which
> is meant for python <2.7.


The problem here is that assertContains is not part of unittest/unittest2.

It's defined in TransactionTestCase in django.test, which extends 
unittest2.TestCase and adds in assertContains, assertNotContains, 
assetFormError, basically django specific assertions.


Mike


-- 
 The real value of KDE is that they inspired and push the
  development of GNOME :-)
-- #Debian

-- 
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.

Re: test cannot find assertContains

[Kenneth Gonsalves]

On Fri, 2011-03-11 at 23:04 -0800, Mike Ramirez wrote:
> > 
> > from django.utils import unittest
> 
> from django.test import TestCase
> 
> the stuff in utils.unittest is unittest2 stuff if you're using python
> <2.7 
> (unittest2 is part of 2.7 now as unittest). 

I am using 2.6, but according to the django docs, django has a bundled
version of unittest2 which is accessed from django.utils.unittest which
is meant for python <2.7.
-- 
regards
KG
http://lawgon.livejournal.com
Coimbatore LUG rox
http://ilugcbe.techstud.org/

-- 
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.

Re: test cannot find assertContains

[Mike Ramirez]

On Friday, March 11, 2011 11:04:39 pm Mike Ramirez wrote:

> assertContains is a django specific test and located in test.TestCase with
> the others (you can find TransactionTestCase in there also).
> 

I should also add, TransactionTestCase is the base for TestCase and TestCase 
is really a patch to convince TransactionTestCase that a transaction occured, 
but the transaction does nothing.

TestCase's docstring:

"Does basically the same as TransactionTestCase, but surrounds every test with 
a transaction, monkey-patches the real transaction management routines to do 
nothing, and rollsback the test transaction at the end of the test. You have 
to use TransactionTestCase, if you need transaction management inside a test."

Mike


-- 
Work without a vision is slavery, Vision without work is a pipe dream,
But vision with work is the hope of the world.

-- 
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.

Re: test cannot find assertContains

[Mike Ramirez]

On Friday, March 11, 2011 10:19:27 pm Kenneth Gonsalves wrote:
> hi,
> 
> I am trying to run a test using assertContains, but get this error:
> 
> AttributeError: 'SourceTestCase' object has no attribute
> 'assertContains'
> 
> my code:
> 
> from django.utils import unittest

from django.test import TestCase

the stuff in utils.unittest is unittest2 stuff if you're using python <2.7 
(unittest2 is part of 2.7 now as unittest).

assertContains is a django specific test and located in test.TestCase with the 
others (you can find TransactionTestCase in there also).


Mike



-- 
The British are coming!  The British are coming!

-- 
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.

test cannot find assertContains

[Kenneth Gonsalves]

hi,

I am trying to run a test using assertContains, but get this error:

AttributeError: 'SourceTestCase' object has no attribute
'assertContains'

my code:

from django.utils import unittest
from incident.models import Source
from django.test.client import Client



class SourceTestCase(unittest.TestCase):
fixtures = ['source.json']
def setUp(self):
self.client = Client()


def testSource(self):
response = self.client.get('/incident/sources/')
self.assertEqual(response.status_code, 200)
self.assertContains(response,'phone')
-- 
regards
KG
http://lawgon.livejournal.com
Coimbatore LUG rox
http://ilugcbe.techstud.org/

-- 
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.

How do I run test and get results programmatically? (django, south, fixtures, sqlite)

[Jumpfroggy]

I have an app that I'm starting to write tests for.  The app uses
south for all migrations and mysql for the db.

I wrote some tests and also created an initial_data.json fixture to
provide some default data.  If I run "python manage.py test", the
database is created via sqlite, the tests are run, and then the report
is spit out.  This works fine.

However, I want to automate this where I can programmatically run
tests, find the failures, and do some custom logging/saving of the
failures.  How do I run the tests in python?

I've tried a few variations of the below code, but the problem is the
database.  When I run the "python manage.py test" command, it
automatically uses sqlite3 as the backend, creates the database, and
uses it for all tests.  However, when I run my own tests, it uses the
mysql backend.  If I force it to use sqlite, is has problems with the
fixtures because the migrations are not run before installing the
fixtures.

How do I run tests manually using the same database setup that happens
when using the manage.py test command?

My code:

import my_application.settings

# NOTE: Use this to force the testing database to use the sqlite
engine.
my_application.settings.DATABASE_ENGINE = 'sqlite3'

from django.core.management import setup_environ
setup_environ(my_application.settings)

from django.conf import settings
from django.test.utils import get_runner

verbosity = 1
interactive = False
failfast = True
TestRunner = get_runner(settings)

test_labels = ()

test_runner = TestRunner(verbosity=verbosity,
interactive=interactive, failfast=failfast)
failures = test_runner.run_tests(test_labels)

And this is the error I get:

calling TestRunner.run_tests()
  verbosity: 1
  interactive: False
  failfast: True
  test_labels: ()
connection.settings_dict: {'ENGINE': 'django.db.backends.sqlite3',
'TEST_MIRROR': None, 'NAME': 'my_application', 'TEST_CHARSET': None,
'TIME_ZONE': 'America/New_York', 'TEST_COLLATION': None, 'OPTIONS':
{}, 'HOST': '', 'USER': 'my_application', 'TEST_NAME': None,
'PASSWORD': 'my_application', 'PORT': ''}
test_databases: {('', '', 'django.db.backends.sqlite3',
'my_application'): ['default']}
Creating test database 'default'...
Syncing...
Creating table django_admin_log
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_user_permissions
Creating table auth_user_groups
Creating table auth_user
Creating table auth_message
Creating table django_content_type
Creating table django_session
Creating table django_site
Creating table south_migrationhistory
Installing index for admin.LogEntry model
Installing index for auth.Permission model
Installing index for auth.Group_permissions model
Installing index for auth.User_user_permissions model
Installing index for auth.User_groups model
Installing index for auth.Message model
No fixtures found.

Synced:
 > django.contrib.admin
 > django.contrib.auth
 > django.contrib.contenttypes
 > django.contrib.sessions
 > django.contrib.sites
 > south

Not synced (use migrations):
 - my_application
(use ./manage.py migrate to migrate these)
test_db_name: ':memory:'
Problem installing fixture 'C:\virtualenv-my_application\lib
\site-packages\django\contrib\auth\fixtures\authtestdata.json':
Traceback (most recent call last):
  File "C:\virtualenv-my_application\lib\site-packages\django\core
\management\commands\loaddata.py", line 174, in handle
obj.save(using=using)
  File "C:\virtualenv-my_application\Lib\site-packages\django\core
\serializers\base.py", line 165, in save
models.Model.save_base(self.object, using=using, raw=True)
  File "C:\virtualenv-my_application\Lib\site-packages\django\db
\models\base.py", line 566, in save_base
created=(not record_exists), raw=raw)
  File "C:\virtualenv-my_application\Lib\site-packages\django
\dispatch\dispatcher.py", line 172, in send
response = receiver(signal=self, sender=sender, **named)
  File "C:\my_application\..\my_application\models.py", line 1175,
in _create_profile_for_user
profile.save()
  File "C:\virtualenv-my_application\Lib\site-packages\django\db
\models\base.py", line 456, in save
self.save_base(using=using, force_insert=force_insert,
force_update=force_update)
  File "C:\virtualenv-my_application\Lib\site-packages\django\db
\models\base.py", line 549, in save_base
result = manager._insert(values, return_id=update_pk,
using=using)
  File "C:\virtualenv-my_application\Lib\site-packages\django\db
\models\manager.py", line 195, in _insert
return insert_query(self.model, values, **kwargs)
  File 

BDD test scenario localisation

[Sultan Imanhodjaev]

Hello,

I was wondering if there any way to localise BDD test according to
project requirement is there any issue?




Sultan

-- 
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.