Re: Running django tests with postgres

[Mike Dewhirst]

Bill

I'm about to disappear for a few days. Thank you very much for your 
suggestions - I'll tackle them when I get back.


Cheers

Mike

On 18/09/2018 11:34 PM, Bill-Torcaso-Oxfam wrote:


I two comments, and as always Your Milage May Vary.

  * I wonder if you have the right indexes on your Postgres database?
The previous people report much faster completion times for test
that use Postgres as the database.  Perhaps your domain is just
hard (and you description makes it sound that way), but "Explain
Plan" might be your best friend here.

  * Sqlite does not enforce length limit constraints on text fields. 
You can declare a field to be CharField(max_length=200), and
Sqlite will happily put a longer string into the field.  Postgres
will not.

This came up when I was importing data from an older generation of
our product.  My custom import code ran successfully against
Sqlite and the exact same command failed against Postgres.

  * (And yes, I said only two points.  But this just occurs to me...)

Can you divide your test suite into distinct independent chunks,
and run them in parallel?  Either against one common database or
using one database per test-chunk?

On Friday, September 14, 2018 at 11:32:49 AM UTC-4, Hezi Halpert wrote:

I would like to share with you an issue we encounter while moving
from sqlite to postgres with heavily use of Django testing.

We have Django app with ~700 tests. Most of them accessing
database. We recently migrated the database from sqlite to postgres.
Many of our tests were written in a way that compares actual pk’s
(hard-coded pks or just file/json comparisons) . Since Django
testing on sqlite (testcases.TestCase class) creates in-memory
database (which is being reseted every unit test by default), we
never had a problem with it.
However, Django TestCase on postgres create completely another
test db which preserves the pk sequences between different tests.
And since many of our tests were written in a way that compares
actual pk’s they all start fail - depends on the exact tests
execution order.
Even tests which expect some pk and are were not failed yet, can
potentially failed in the future - depends on adding/editing other
tests which may change the db sequence

We consider the following solutions:

 1. Move to TransactionTestCase (instead of TestCase) and use
“reset_sequences = True” flag. Cons:
TransactionTestCase reduces performance dramatically (~4 times
longer in some of the tests)
 2. Refactor all failed tests: remove all hard-coded references to
the pk. Cons: Require much Dev effort (we had more then 70
such tests)
 3. Route the database in settings.py such it will use sqlite
instead of postgres when running tests. Cons: It will not
actually test the real scenarios - not an option
 4. Combine reset_sequences flag with TestCase in our own version
to TestCase: OurTestCase class and make everything to inherit
from it. This is the option we finally decided of. See below.


fromdjango.test import TestCase, testcases

class OurTestCase(TestCase):
 reset_sequences =True def _fixture_setup(self):
 for db_namein self._databases_names(include_mirrors=False):
if self.reset_sequences:
 self._reset_sequences(db_name)
 if self.fixtures:
call_command('loaddata', *self.fixtures, **{'verbosity':0,'database': 
db_name})
 if not testcases.connections_support_transactions():
self.setUpTestData()
 return super(TestCase,self)._fixture_setup()
 self.atomics =self._enter_atomics()

Another problem of these kind of tests is the default ordering
assumption of Django which changes significantly between postgres
and sqlite when testing.
Therefore, models included in such tests must have a hint for
Django regarding the default ordering retrieval.
Our solution was to make all models inherit from
DexterModelDefaultOrder (below)


class DexterModelDefaultOrder(models.Model):
 class Meta:
 abstract =True ordering = ['id']

I hope it (will) help someone

--
You received this message because you are subscribed to the Google 
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-users+unsubscr...@googlegroups.com 
.
To post to this group, send email to django-users@googlegroups.com 
.

Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/1e8ec552-d793-4161-ba10-070263586698%40googlegroups.com 

Re: Running django tests with postgres

[Bill-Torcaso-Oxfam]

I two comments, and as always Your Milage May Vary.


   - I wonder if you have the right indexes on your Postgres database? The 
   previous people report much faster completion times for test that use 
   Postgres as the database.  Perhaps your domain is just hard (and you 
   description makes it sound that way), but "Explain Plan" might be your best 
   friend here.
   
   - Sqlite does not enforce length limit constraints on text fields.  You 
   can declare a field to be CharField(max_length=200), and Sqlite will 
   happily put a longer string into the field.  Postgres will not.
   
   This came up when I was importing data from an older generation of our 
   product.  My custom import code ran successfully against Sqlite and the 
   exact same command failed against Postgres.
   
   - (And yes, I said only two points.  But this just occurs to me...)
   
   Can you divide your test suite into distinct independent chunks, and run 
   them in parallel?  Either against one common database or using one database 
   per test-chunk?
   
   
On Friday, September 14, 2018 at 11:32:49 AM UTC-4, Hezi Halpert wrote:
>
> I would like to share with you an issue we encounter while moving from 
> sqlite to postgres with heavily use of Django testing.
>
> We have Django app with ~700 tests. Most of them accessing database. We 
> recently migrated the database from sqlite to postgres. 
> Many of our tests were written in a way that compares actual pk’s 
> (hard-coded pks or just file/json comparisons) . Since Django testing on 
> sqlite (testcases.TestCase class) creates in-memory database (which is 
> being reseted every unit test by default), we never had a problem with it.
> However, Django TestCase on postgres create completely another test db 
> which preserves the pk sequences between different tests. And since many of 
> our tests were written in a way that compares actual pk’s they all start 
> fail - depends on the exact tests execution order.
> Even tests which expect some pk and are were not failed yet, can 
> potentially failed in the future - depends on adding/editing other tests 
> which may change the db sequence
>
> We consider the following solutions:
>
>1. Move to TransactionTestCase (instead of TestCase) and use 
>“reset_sequences = True” flag. Cons: TransactionTestCase reduces 
>performance dramatically (~4 times longer in some of the tests) 
>2. Refactor all failed tests: remove all hard-coded references to the 
>pk. Cons: Require much Dev effort (we had more then 70 such tests)
>3. Route the database in settings.py such it will use sqlite instead 
>of postgres when running tests. Cons: It will not actually test the real 
>scenarios - not an option
>4. Combine reset_sequences flag with TestCase in our own version to 
>TestCase: OurTestCase class and make everything to inherit from it. This 
> is 
>the option we finally decided of. See below.
>
>
> from django.test import TestCase, testcases
>
>
> class OurTestCase(TestCase):
> reset_sequences = True
>
> def _fixture_setup(self):
> for db_name in self._databases_names(include_mirrors=False):
> if self.reset_sequences:
> self._reset_sequences(db_name)
> if self.fixtures:
> call_command('loaddata', *self.fixtures, **{'verbosity': 0, 
> 'database': db_name})
> if not testcases.connections_support_transactions():
> self.setUpTestData()
> return super(TestCase, self)._fixture_setup()
> self.atomics = self._enter_atomics()
>
>
> Another problem of these kind of tests is the default ordering assumption 
> of Django which changes significantly between postgres and sqlite when 
> testing.
> Therefore, models included in such tests must have a hint for Django 
> regarding the default ordering retrieval. 
> Our solution was to make all models inherit from DexterModelDefaultOrder 
> (below) 
>
>
> class DexterModelDefaultOrder(models.Model):
> class Meta:
> abstract = True
> ordering = ['id']
>
>
>
> I hope it (will) help someone
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/1e8ec552-d793-4161-ba10-070263586698%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Running django tests with postgres

[Mike Dewhirst]

My software classifies chemical hazards according to intrinsic physical 
properties. This requires accessing large quantities of reference data 
imported from jurisdictions around the world. The tests demand correct 
classification for known properties.


There are dozens of different classification types for physical, health 
and environmental hazards. Here is the current spec ...

https://www.unece.org/trans/danger/publi/ghs/ghs_rev07/07files_e0.html

Then we have transport hazards based on UN reference data for air, sea 
and land transport. Here is the current spec ...

https://www.unece.org/trans/danger/publi/unrec/rev20/20files_track_e.html

Then there are regulatory workplace exposure limits and biological 
monitoring criteria which has to be fetched from more reference tables 
based on jurisdictions specified.


Then there are mixtures. Known properties of ingredients in various 
proportions produc different classifications. The software (and tests) 
must classify a mixture correctly. Some ingredients react together in 
known stoichiometric proportions to form a reaction product with its own 
known properties. In such a mixture partly reacted like that the tests 
have to prove correct classification.


Some of the properties are common and some depend on whether a substance 
is gas, liquid or solid. Nano is another. So there are core 
classification methods plus a separate set each for gas, liquid and 
solid. Then there are other sets for different acute toxicity routes 
(skin, inhalation, ingestion), chronic toxicity, specific organ toxicity 
for single and multiple exposures, explosion characteristics, oxidizing 
properties, corrosive to metal, skin and eyes, carcinogenicity, 
mutagenicity, ototoxicity and the list continues with aquatic and other 
environmental classifications.


There is more but I really have difficulty working out how to test 
end-points without invoking the calculations which in turn require 
construction of test substances and mixtures with model methods doing 
self-classification according to assigned test properties and the 
reference material.


On the topic of testing via SQLite3 when the production environment uses 
Postgres, I have found remarkably identical behaviour. Provided you 
*also* test with the same DBMS I see no problem.


Nothing gets into production without being tested with Postgres using 
BuildBot to manage it. As it happens the development server always uses 
Postgres. I have the option of testing in development with either 
SQLite3 or Postgres but cannot remember the last time I tested in 
development with Postgres.


Most of my dev testing is restricted to individual test classes which 
run relatively (for me!) quickly. I only run the full suite when I head 
off to lunch or Pilates or for a bike ride.


However, I would love my tests to run as fast as yours. How much would 
you charge me to make that happen?


Cheers

Mike

On 16/09/2018 3:33 AM, Jason wrote:
Agreed.  Something is definitely off.  At work, the legacy monolith 
django app has about 7800 tests.  It takes about 18 minutes to run the 
full test suite in docker with the latest MBP (four cores, 5GB RAM 
allocated in docker machine), including creating the db and four 
parallel test streams running.  A smaller service I work on has about 
780 tests, and it takes about 4 minutes to run in total.  And like 
Andreas, I find that too long at times!

--
You received this message because you are subscribed to the Google 
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-users+unsubscr...@googlegroups.com 
.
To post to this group, send email to django-users@googlegroups.com 
.

Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/07a56866-c2ef-4bf3-8349-a5faa54e7d28%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5e6d7abd-fbf4-3664-ad18-0881c68d40b3%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

Re: Running django tests with postgres

[Jason]

Agreed.  Something is definitely off.  At work, the legacy monolith django 
app has about 7800 tests.  It takes about 18 minutes to run the full test 
suite in docker with the latest MBP (four cores, 5GB RAM allocated in 
docker machine), including creating the db and four parallel test streams 
running.  A smaller service I work on has about 780 tests, and it takes 
about 4 minutes to run in total.  And like Andreas, I find that too long at 
times!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/07a56866-c2ef-4bf3-8349-a5faa54e7d28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Running django tests with postgres

[Andréas Kühne]

I would just be scared that some minor issues are different between the
database implementations - therefore some test that would work in the tests
and during development, doesn't work in production.

I usually try to use the same things in production and development (or as
close as possible).

That being said - Tests that take 300 minutes is just too much :-)

We have around 750 tests are it takes around 5 minutes to run - Something
that I find to be too long still

Regards,

Andréas


Den lör 15 sep. 2018 kl 02:29 skrev Mike Dewhirst :

> +1 Andréas
>
> One of my projects runs (currently) 1,248 tests using SQLite3 in 72
> minutes on my local Windows 10 dev laptop. That laptop has both a SSD
> and a hard disk. Foolishly I opted to use the SSD for software
> installations and the hard disk for development and thus the tests. I
> was concerned that overexercising the SSD might wear it out. I've since
> been advised that I shouldn't worry so one of these days I'll reorganise
> things and maybe see that 72 minutes drop somewhat.
>
> However, those same tests take 285 minutes on a headless PC running
> Ubuntu 16.04 LTS server with Postgres 9.6
>
> There are only one or two tests which generate slightly different error
> messages between SQLite3 and Postgres and that is trivial to manage.
>
> Most tests are database heavy, requiring queries and calling/testing
> model methods.
>
> Consequently, I use - and recommend - SQLite for dev tests and Postgres
> for deployment testing.
>
> Cheers
>
> Mike
>
> On 15/09/2018 1:45 AM, Andréas Kühne wrote:
> > Hi,
> >
> > Just my 5 cents. I think you are doing the tests wrong. I don't
> > believe that doing testing against hard coded values is at all correct
> > - and it isn't actually that hard to change the tests to a simpler
> > way. The values of the PK's aren't really necessary for your test to
> > be true either - how does that translate to a real use case? You
> > should probably check for A value in the pk field, but not a specific
> > value, because that doesn't result in any added value for your customer?
> >
> > Also changing the way django runs tests feels like working against the
> > framework rather than with it? I would probably much prefer changing
> > the tests than changing the way the framework runs my tests
> > Another issue you may face is if Django changes the underlying code,
> > then you will get strange failures as well...
> >
> > I don't think that 70 tests is that much to change either - we work
> > with a project that could fail a considerable amount of tests during a
> > refactor - and then we need to fix them. The same goes here I think -
> > you did a change to the infrastructure that made the tests invalid -
> > rewrite the tests :-)
> >
> > Best regards,
> >
> > Andréas
> >
> >
> > Den fre 14 sep. 2018 kl 17:32 skrev Hezi Halpert  > >:
> >
> > I would like to share with you an issue we encounter while moving
> > from sqlite to postgres with heavily use of Django testing.
> >
> > We have Django app with ~700 tests. Most of them accessing
> > database. We recently migrated the database from sqlite to postgres.
> > Many of our tests were written in a way that compares actual pk’s
> > (hard-coded pks or just file/json comparisons) . Since Django
> > testing on sqlite (testcases.TestCase class) creates in-memory
> > database (which is being reseted every unit test by default), we
> > never had a problem with it.
> > However, Django TestCase on postgres create completely another
> > test db which preserves the pk sequences between different tests.
> > And since many of our tests were written in a way that compares
> > actual pk’s they all start fail - depends on the exact tests
> > execution order.
> > Even tests which expect some pk and are were not failed yet, can
> > potentially failed in the future - depends on adding/editing other
> > tests which may change the db sequence
> >
> > We consider the following solutions:
> >
> >  1. Move to TransactionTestCase (instead of TestCase) and use
> > “reset_sequences = True” flag. Cons:
> > TransactionTestCase reduces performance dramatically (~4 times
> > longer in some of the tests)
> >  2. Refactor all failed tests: remove all hard-coded references to
> > the pk. Cons: Require much Dev effort (we had more then 70
> > such tests)
> >  3. Route the database in settings.py such it will use sqlite
> > instead of postgres when running tests. Cons: It will not
> > actually test the real scenarios - not an option
> >  4. Combine reset_sequences flag with TestCase in our own version
> > to TestCase: OurTestCase class and make everything to inherit
> > from it. This is the option we finally decided of. See below.
> >
> >
> > fromdjango.test import TestCase, testcases
> >
> > class OurTestCase(TestCase):
> >

Re: Running django tests with postgres

[Mike Dewhirst]

+1 Andréas

One of my projects runs (currently) 1,248 tests using SQLite3 in 72 
minutes on my local Windows 10 dev laptop. That laptop has both a SSD 
and a hard disk. Foolishly I opted to use the SSD for software 
installations and the hard disk for development and thus the tests. I 
was concerned that overexercising the SSD might wear it out. I've since 
been advised that I shouldn't worry so one of these days I'll reorganise 
things and maybe see that 72 minutes drop somewhat.


However, those same tests take 285 minutes on a headless PC running 
Ubuntu 16.04 LTS server with Postgres 9.6


There are only one or two tests which generate slightly different error 
messages between SQLite3 and Postgres and that is trivial to manage.


Most tests are database heavy, requiring queries and calling/testing 
model methods.


Consequently, I use - and recommend - SQLite for dev tests and Postgres 
for deployment testing.


Cheers

Mike

On 15/09/2018 1:45 AM, Andréas Kühne wrote:

Hi,

Just my 5 cents. I think you are doing the tests wrong. I don't 
believe that doing testing against hard coded values is at all correct 
- and it isn't actually that hard to change the tests to a simpler 
way. The values of the PK's aren't really necessary for your test to 
be true either - how does that translate to a real use case? You 
should probably check for A value in the pk field, but not a specific 
value, because that doesn't result in any added value for your customer?


Also changing the way django runs tests feels like working against the 
framework rather than with it? I would probably much prefer changing 
the tests than changing the way the framework runs my tests 
Another issue you may face is if Django changes the underlying code, 
then you will get strange failures as well...


I don't think that 70 tests is that much to change either - we work 
with a project that could fail a considerable amount of tests during a 
refactor - and then we need to fix them. The same goes here I think - 
you did a change to the infrastructure that made the tests invalid - 
rewrite the tests :-)


Best regards,

Andréas


Den fre 14 sep. 2018 kl 17:32 skrev Hezi Halpert >:


I would like to share with you an issue we encounter while moving
from sqlite to postgres with heavily use of Django testing.

We have Django app with ~700 tests. Most of them accessing
database. We recently migrated the database from sqlite to postgres.
Many of our tests were written in a way that compares actual pk’s
(hard-coded pks or just file/json comparisons) . Since Django
testing on sqlite (testcases.TestCase class) creates in-memory
database (which is being reseted every unit test by default), we
never had a problem with it.
However, Django TestCase on postgres create completely another
test db which preserves the pk sequences between different tests.
And since many of our tests were written in a way that compares
actual pk’s they all start fail - depends on the exact tests
execution order.
Even tests which expect some pk and are were not failed yet, can
potentially failed in the future - depends on adding/editing other
tests which may change the db sequence

We consider the following solutions:

 1. Move to TransactionTestCase (instead of TestCase) and use
“reset_sequences = True” flag. Cons:
TransactionTestCase reduces performance dramatically (~4 times
longer in some of the tests)
 2. Refactor all failed tests: remove all hard-coded references to
the pk. Cons: Require much Dev effort (we had more then 70
such tests)
 3. Route the database in settings.py such it will use sqlite
instead of postgres when running tests. Cons: It will not
actually test the real scenarios - not an option
 4. Combine reset_sequences flag with TestCase in our own version
to TestCase: OurTestCase class and make everything to inherit
from it. This is the option we finally decided of. See below.


fromdjango.test import TestCase, testcases

class OurTestCase(TestCase):
 reset_sequences =True def _fixture_setup(self):
 for db_namein self._databases_names(include_mirrors=False):
if self.reset_sequences:
 self._reset_sequences(db_name)
 if self.fixtures:
call_command('loaddata', *self.fixtures, **{'verbosity':0,'database': 
db_name})
 if not testcases.connections_support_transactions():
self.setUpTestData()
 return super(TestCase,self)._fixture_setup()
 self.atomics =self._enter_atomics()

Another problem of these kind of tests is the default ordering
assumption of Django which changes significantly between postgres
and sqlite when testing.
Therefore, models included in such tests must have a hint for
Django regarding the default ordering retrieval.
Our 

Re: Running django tests with postgres

[Andréas Kühne]

Hi,

Just my 5 cents. I think you are doing the tests wrong. I don't believe
that doing testing against hard coded values is at all correct - and it
isn't actually that hard to change the tests to a simpler way. The values
of the PK's aren't really necessary for your test to be true either - how
does that translate to a real use case? You should probably check for A
value in the pk field, but not a specific value, because that doesn't
result in any added value for your customer?

Also changing the way django runs tests feels like working against the
framework rather than with it? I would probably much prefer changing the
tests than changing the way the framework runs my tests Another issue
you may face is if Django changes the underlying code, then you will get
strange failures as well...

I don't think that 70 tests is that much to change either - we work with a
project that could fail a considerable amount of tests during a refactor -
and then we need to fix them. The same goes here I think - you did a change
to the infrastructure that made the tests invalid - rewrite the tests :-)

Best regards,

Andréas


Den fre 14 sep. 2018 kl 17:32 skrev Hezi Halpert :

> I would like to share with you an issue we encounter while moving from
> sqlite to postgres with heavily use of Django testing.
>
> We have Django app with ~700 tests. Most of them accessing database. We
> recently migrated the database from sqlite to postgres.
> Many of our tests were written in a way that compares actual pk’s
> (hard-coded pks or just file/json comparisons) . Since Django testing on
> sqlite (testcases.TestCase class) creates in-memory database (which is
> being reseted every unit test by default), we never had a problem with it.
> However, Django TestCase on postgres create completely another test db
> which preserves the pk sequences between different tests. And since many of
> our tests were written in a way that compares actual pk’s they all start
> fail - depends on the exact tests execution order.
> Even tests which expect some pk and are were not failed yet, can
> potentially failed in the future - depends on adding/editing other tests
> which may change the db sequence
>
> We consider the following solutions:
>
>1. Move to TransactionTestCase (instead of TestCase) and use
>“reset_sequences = True” flag. Cons: TransactionTestCase reduces
>performance dramatically (~4 times longer in some of the tests)
>2. Refactor all failed tests: remove all hard-coded references to the
>pk. Cons: Require much Dev effort (we had more then 70 such tests)
>3. Route the database in settings.py such it will use sqlite instead
>of postgres when running tests. Cons: It will not actually test the real
>scenarios - not an option
>4. Combine reset_sequences flag with TestCase in our own version to
>TestCase: OurTestCase class and make everything to inherit from it. This is
>the option we finally decided of. See below.
>
>
> from django.test import TestCase, testcases
>
>
> class OurTestCase(TestCase):
> reset_sequences = True
>
> def _fixture_setup(self):
> for db_name in self._databases_names(include_mirrors=False):
> if self.reset_sequences:
> self._reset_sequences(db_name)
> if self.fixtures:
> call_command('loaddata', *self.fixtures, **{'verbosity': 0, 
> 'database': db_name})
> if not testcases.connections_support_transactions():
> self.setUpTestData()
> return super(TestCase, self)._fixture_setup()
> self.atomics = self._enter_atomics()
>
>
> Another problem of these kind of tests is the default ordering assumption
> of Django which changes significantly between postgres and sqlite when
> testing.
> Therefore, models included in such tests must have a hint for Django
> regarding the default ordering retrieval.
> Our solution was to make all models inherit from DexterModelDefaultOrder
> (below)
>
>
> class DexterModelDefaultOrder(models.Model):
> class Meta:
> abstract = True
> ordering = ['id']
>
>
>
> I hope it (will) help someone
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/ffcd3cc9-c3be-44ba-9665-a4ded5fed492%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe 

Running django tests with postgres

[Hezi Halpert]

I would like to share with you an issue we encounter while moving from 
sqlite to postgres with heavily use of Django testing.

We have Django app with ~700 tests. Most of them accessing database. We 
recently migrated the database from sqlite to postgres. 
Many of our tests were written in a way that compares actual pk’s 
(hard-coded pks or just file/json comparisons) . Since Django testing on 
sqlite (testcases.TestCase class) creates in-memory database (which is 
being reseted every unit test by default), we never had a problem with it.
However, Django TestCase on postgres create completely another test db 
which preserves the pk sequences between different tests. And since many of 
our tests were written in a way that compares actual pk’s they all start 
fail - depends on the exact tests execution order.
Even tests which expect some pk and are were not failed yet, can 
potentially failed in the future - depends on adding/editing other tests 
which may change the db sequence

We consider the following solutions:

   1. Move to TransactionTestCase (instead of TestCase) and use 
   “reset_sequences = True” flag. Cons: TransactionTestCase reduces 
   performance dramatically (~4 times longer in some of the tests) 
   2. Refactor all failed tests: remove all hard-coded references to the 
   pk. Cons: Require much Dev effort (we had more then 70 such tests)
   3. Route the database in settings.py such it will use sqlite instead of 
   postgres when running tests. Cons: It will not actually test the real 
   scenarios - not an option
   4. Combine reset_sequences flag with TestCase in our own version to 
   TestCase: OurTestCase class and make everything to inherit from it. This is 
   the option we finally decided of. See below.
   

from django.test import TestCase, testcases


class OurTestCase(TestCase):
reset_sequences = True

def _fixture_setup(self):
for db_name in self._databases_names(include_mirrors=False):
if self.reset_sequences:
self._reset_sequences(db_name)
if self.fixtures:
call_command('loaddata', *self.fixtures, **{'verbosity': 0, 
'database': db_name})
if not testcases.connections_support_transactions():
self.setUpTestData()
return super(TestCase, self)._fixture_setup()
self.atomics = self._enter_atomics()


Another problem of these kind of tests is the default ordering assumption 
of Django which changes significantly between postgres and sqlite when 
testing.
Therefore, models included in such tests must have a hint for Django 
regarding the default ordering retrieval. 
Our solution was to make all models inherit from DexterModelDefaultOrder 
(below) 


class DexterModelDefaultOrder(models.Model):
class Meta:
abstract = True
ordering = ['id']



I hope it (will) help someone

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/ffcd3cc9-c3be-44ba-9665-a4ded5fed492%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Running Django tests for postgres_tests

[Tim Graham]

You need to use a custom settings module that uses the postgresql database 
backend.

https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/#using-another-settings-module

On Tuesday, July 19, 2016 at 11:37:35 PM UTC-4, premdjango wrote:
>
> I'm trying to run django tests for a particular module - postgres_tests. 
> The tests runs but it says it skipped=312 tests, I believe none of the test 
> case run.
>
>
> How do I fix this issue?
>
>
>
>
> (djangodev) Anands-MBP:tests laks$ ./runtests.py postgres_tests
>
> Testing against Django installed in 
> '/Users/premanandlakshmanan/Documents/django-contribute/django/django' with 
> up to 8 processes
>
> Creating test database for alias 'default'...
>
> Cloning test database for alias 'default'...
>
> Cloning test database for alias 'default'...
>
> Cloning test database for alias 'default'...
>
> Cloning test database for alias 'default'...
>
> Cloning test database for alias 'default'...
>
> Cloning test database for alias 'default'...
>
> Cloning test database for alias 'default'...
>
> Cloning test database for alias 'default'...
>
> Creating test database for alias 'other'...
>
> Cloning test database for alias 'other'...
>
> Cloning test database for alias 'other'...
>
> Cloning test database for alias 'other'...
>
> Cloning test database for alias 'other'...
>
> Cloning test database for alias 'other'...
>
> Cloning test database for alias 'other'...
>
> Cloning test database for alias 'other'...
>
> Cloning test database for alias 'other'...
>
>
> 
>
> --
>
> Ran 312 tests in 0.149s
>
>
> OK (skipped=312)
>
> Destroying test database for alias 'default'...
>
> Destroying test database for alias 'default'...
>
> Destroying test database for alias 'default'...
>
> Destroying test database for alias 'default'...
>
> Destroying test database for alias 'default'...
>
> Destroying test database for alias 'default'...
>
> Destroying test database for alias 'default'...
>
> Destroying test database for alias 'default'...
>
> Destroying test database for alias 'default'...
>
> Destroying test database for alias 'other'...
>
> Destroying test database for alias 'other'...
>
> Destroying test database for alias 'other'...
>
> Destroying test database for alias 'other'...
>
> Destroying test database for alias 'other'...
>
> Destroying test database for alias 'other'...
>
> Destroying test database for alias 'other'...
>
> Destroying test database for alias 'other'...
>
> Destroying test database for alias 'other'...
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/2b7bfb89-8fcb-4598-9329-087331ff8dc8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Running Django tests for postgres_tests

[premdjango]

 

I'm trying to run django tests for a particular module - postgres_tests. 
The tests runs but it says it skipped=312 tests, I believe none of the test 
case run.


How do I fix this issue?




(djangodev) Anands-MBP:tests laks$ ./runtests.py postgres_tests

Testing against Django installed in 
'/Users/premanandlakshmanan/Documents/django-contribute/django/django' with 
up to 8 processes

Creating test database for alias 'default'...

Cloning test database for alias 'default'...

Cloning test database for alias 'default'...

Cloning test database for alias 'default'...

Cloning test database for alias 'default'...

Cloning test database for alias 'default'...

Cloning test database for alias 'default'...

Cloning test database for alias 'default'...

Cloning test database for alias 'default'...

Creating test database for alias 'other'...

Cloning test database for alias 'other'...

Cloning test database for alias 'other'...

Cloning test database for alias 'other'...

Cloning test database for alias 'other'...

Cloning test database for alias 'other'...

Cloning test database for alias 'other'...

Cloning test database for alias 'other'...

Cloning test database for alias 'other'...



--

Ran 312 tests in 0.149s


OK (skipped=312)

Destroying test database for alias 'default'...

Destroying test database for alias 'default'...

Destroying test database for alias 'default'...

Destroying test database for alias 'default'...

Destroying test database for alias 'default'...

Destroying test database for alias 'default'...

Destroying test database for alias 'default'...

Destroying test database for alias 'default'...

Destroying test database for alias 'default'...

Destroying test database for alias 'other'...

Destroying test database for alias 'other'...

Destroying test database for alias 'other'...

Destroying test database for alias 'other'...

Destroying test database for alias 'other'...

Destroying test database for alias 'other'...

Destroying test database for alias 'other'...

Destroying test database for alias 'other'...

Destroying test database for alias 'other'...

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/61d80db1-f3fd-467d-bd07-ba0cc45c9eef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

InterfaceError: connection already closed from psycopg2 when running Django Tests

[TheBeardedTemplar]

I'm trying to implement testing on a fairly large Django site, and I'm 
encountering a psycopg2 error when running all the tests at once using 
`python manage.py test`. If I specify each app name individually, it works 
fine (some tests fail, but all for legitimate reasons), however when I run 
them all at once, it works as expected for the first 20-30 tests, and then 
I get a large number failing at once, all with an interface error.

==
ERROR: testFunctionality (proj.apps.myapp.tests.AppFunction)

--
Traceback (most recent call last):
  File "C:\projects\WidgetCo\src\django\widget\apps\app\tests.py", 
line 31, in setUp
data.createClients()
  File "C:\projects\WidgetCo\src\django\testApp\data.py", line 61, 
in createClients
createCompanies()
  File "C:\projects\WidgetCo\src\django\testApp\data.py", line 54, 
in createCompanies
company1.save()
  File "C:\Python27\lib\site-packages\django\db\models\base.py", 
line 710, in save
force_update=force_update, update_fields=update_fields)
  File "C:\Python27\lib\site-packages\django\db\models\base.py", 
line 738, in save_base
updated = self._save_table(raw, cls, force_insert, force_update, 
using, update_fields)
  File "C:\Python27\lib\site-packages\django\db\models\base.py", 
line 822, in _save_table
result = self._do_insert(cls._base_manager, using, fields, 
update_pk, raw)
  File "C:\Python27\lib\site-packages\django\db\models\base.py", 
line 861, in _do_insert
using=using, raw=raw)
  File "C:\Python27\lib\site-packages\django\db\models\manager.py", 
line 127, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "C:\Python27\lib\site-packages\django\db\models\query.py", 
line 920, in _insert
return query.get_compiler(using=using).execute_sql(return_id)
  File 
"C:\Python27\lib\site-packages\django\db\models\sql\compiler.py", line 972, 
in execute_sql
with self.connection.cursor() as cursor:
  File 
"C:\Python27\lib\site-packages\django\db\backends\base\base.py", line 164, 
in cursor
cursor = self.make_cursor(self._cursor())
  File 
"C:\Python27\lib\site-packages\django\db\backends\base\base.py", line 137, 
in _cursor
return self.create_cursor()
  File "C:\Python27\lib\site-packages\django\db\utils.py", line 97, 
in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
  File 
"C:\Python27\lib\site-packages\django\db\backends\base\base.py", line 137, 
in _cursor
return self.create_cursor()
  File 
"C:\Python27\lib\site-packages\django\db\backends\postgresql_psycopg2\base.py"
, line 212, in create_cursor
cursor = self.connection.cursor()
InterfaceError: connection already closed


It looks like the postgresql database is closing mid-test, but I'm not sure 
why or how to stop it. I've tried setting a really high value for 
CONN_MAX_AGE as well as leaving it as default (never close). I've looked at 
the test where it starts to fail (it's always the same one) and nothing 
appears out of the ordinary. Any suggestions would be appreciated.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/a8e52742-9e20-4854-b2ab-e972a7e54b1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Running Django tests from Python

[Shawn Milochik]

On 04/27/2011 04:06 PM, Kenny Meyer wrote:

Hi Shawn,

http://docs.djangoproject.com/en/dev/ref/django-admin/#running-management-commands-from-your-code

Does this answer your question?

Kenny


Never mind. More pdb action and I figured out that I had overwritten 
DJANGO_SETTINGS_MODULE at the bash prompt I was using to try this. All 
my fault. Yay.


Now it works, thanks.

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: Running Django tests from Python

[Shawn Milochik]

On 04/27/2011 04:06 PM, Kenny Meyer wrote:

Hi Shawn,

http://docs.djangoproject.com/en/dev/ref/django-admin/#running-management-commands-from-your-code

Does this answer your question?

Kenny


Kenny,

This is *exactly* what I was looking for.

Unfortunately it doesn't work. It keeps saying that an app with that 
label can not be found.


I've traced it down to django.db.models.loading.py, which imports 
settings from django.conf, but it's
always 'django.conf.LazySettings object' instead of the proper settings 
file.


This is odd, because os.environ['DJANGO_SETTINGS_MODULE'] is properly 
set if I check it in pdb during that function.


I've even tried passing my settings module as a kwarg as described in 
the doc you sent which doesn't work either.

In any case, I'm using the default -- 'settings.py' in the project folder.

Any ideas?

Thanks,
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: Running Django tests from Python

[Kenny Meyer]

Hi Shawn,

http://docs.djangoproject.com/en/dev/ref/django-admin/#running-management-commands-from-your-code

Does this answer your question?

Kenny



On Wed, Apr 27, 2011 at 12:41 PM, Shawn Milochik  wrote:
> Sorry, I realize that last post is missing the context of the original
> question.
> Please see
> this: https://groups.google.com/d/topic/django-users/-4f3J1bJ10k/discussion
> Thanks,
> 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.
>

-- 
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: Running Django tests from Python

[Shawn Milochik]

Sorry, I realize that last post is missing the context of the original 
question.

Please see 
this: https://groups.google.com/d/topic/django-users/-4f3J1bJ10k/discussion

Thanks,
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: Running Django tests from Python

[Shawn Milochik]

I figure it's been long enough that I can bump this post.

I'm currently using subprocess to do this. There must be an easy way to 
simply invoke the tests from within Python.

So, how do you (within Python), do the equivalent of the following?:
./manage.py test myapp1, myapp2, myapp3

Thanks,
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 Django tests from Python

[Shawn Milochik]

I want to use pyinotify[1] to monitor my project directory and run my
unit tests whenever I save a .py file.

The monitoring part is working. All I need now is to know how to call
the tests from my "watcher" script.

As noted in the docs[2], I'm already running  setup_test_environment()
in my script.

Now, how do I do the equivalent of the following from within my Python script?
python manage.py test myapp1 myapp2

[1] https://github.com/seb-m/pyinotify
[2] 
http://docs.djangoproject.com/en/1.3/topics/testing/#running-tests-outside-the-test-runner

Thanks,
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: Running django tests

[Filip Gruszczyński]

Indeed it helped. Thanks a lot, Karen.

2009/8/10 Karen Tracey :
> 2009/8/10 Filip Gruszczyński 
>>
>> Hi!
>>
>> I would like to run django source code tests, but as soon as I do it
>> (after specifying the settings file), I get all kinds of exceptions.
>> Any idea, what am I doing wrong? I post the exceptions below.
>>
>> grusz...@gruszczy-laptop:~/django/tests# PYTHONPATH=..
>
> You appear to be on a Unix-y platform so you'll need to export PYTHONPATH:
>
> export PYTHONPATH=..
>
> so that the setting will be inherited by the runtests script.
>
>>
>> grusz...@gruszczy-laptop:~/django/tests# ./runtests.py --settings=settings
>> Error while importing defer:  File "./runtests.py", line 134, in
>> django_tests
>>    mod = load_app(model_label)
>> File "/var/lib/python-support/python2.6/django/db/models/loading.py",
>> line 72, in load_app
>>    mod = __import__(app_name, {}, {}, ['models'])
>>  File "/root/django/tests/modeltests/defer/models.py", line 6, in 
>>    from django.db.models.query_utils import DeferredAttribute
>> ImportError: cannot import name DeferredAttribute
>
> Notice you are running the tests in /root/django/tests/ but the Django code
> that has been found is /var/lib/python-support/python2.6/django.
>
> This is a symptom of your PYTHONPATH setting not working, and all the import
> errors are likely due to your trying to run new tests against an old level
> of the code.  DeferredAttributed no doubt didn't exist in
> django.db.models.query_utils in whatever version of Django you have
> installed in /var/lib/python-support.
>
> Fix the PYTHONPATH setting and things should go better.
>
> Karen
>
> >
>



-- 
Filip Gruszczyński

--~--~-~--~~~---~--~~
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: Running django tests

[Karen Tracey]

2009/8/10 Filip Gruszczyński 

>
> Hi!
>
> I would like to run django source code tests, but as soon as I do it
> (after specifying the settings file), I get all kinds of exceptions.
> Any idea, what am I doing wrong? I post the exceptions below.
>
> grusz...@gruszczy-laptop:~/django/tests# PYTHONPATH=..


You appear to be on a Unix-y platform so you'll need to export PYTHONPATH:

export PYTHONPATH=..

so that the setting will be inherited by the runtests script.


>
> grusz...@gruszczy-laptop:~/django/tests# ./runtests.py --settings=settings
> Error while importing defer:  File "./runtests.py", line 134, in
> django_tests
>mod = load_app(model_label)
> File "/var/lib/python-support/python2.6/django/db/models/loading.py",
> line 72, in load_app
>mod = __import__(app_name, {}, {}, ['models'])
>  File "/root/django/tests/modeltests/defer/models.py", line 6, in 
>from django.db.models.query_utils import DeferredAttribute
> ImportError: cannot import name DeferredAttribute


Notice you are running the tests in /root/django/tests/ but the Django code
that has been found is /var/lib/python-support/python2.6/django.

This is a symptom of your PYTHONPATH setting not working, and all the import
errors are likely due to your trying to run new tests against an old level
of the code.  DeferredAttributed no doubt didn't exist in
django.db.models.query_utils in whatever version of Django you have
installed in /var/lib/python-support.

Fix the PYTHONPATH setting and things should go better.

Karen

--~--~-~--~~~---~--~~
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 django tests

[Filip Gruszczyński]

Hi!

I would like to run django source code tests, but as soon as I do it
(after specifying the settings file), I get all kinds of exceptions.
Any idea, what am I doing wrong? I post the exceptions below.

grusz...@gruszczy-laptop:~/django/tests# PYTHONPATH=..
grusz...@gruszczy-laptop:~/django/tests# ./runtests.py --settings=settings
Error while importing defer:  File "./runtests.py", line 134, in django_tests
mod = load_app(model_label)
  File "/var/lib/python-support/python2.6/django/db/models/loading.py",
line 72, in load_app
mod = __import__(app_name, {}, {}, ['models'])
  File "/root/django/tests/modeltests/defer/models.py", line 6, in 
from django.db.models.query_utils import DeferredAttribute
ImportError: cannot import name DeferredAttribute
Error while importing proxy_models:  File "./runtests.py", line 134,
in django_tests
mod = load_app(model_label)
  File "/var/lib/python-support/python2.6/django/db/models/loading.py",
line 72, in load_app
mod = __import__(app_name, {}, {}, ['models'])
  File "/root/django/tests/modeltests/proxy_models/models.py", line
42, in 
class MyPerson(Person):
  File "/var/lib/python-support/python2.6/django/db/models/base.py",
line 55, in __new__
new_class.add_to_class('_meta', Options(meta, **kwargs))
  File "/var/lib/python-support/python2.6/django/db/models/base.py",
line 164, in add_to_class
value.contribute_to_class(cls, name)
  File "/var/lib/python-support/python2.6/django/db/models/options.py",
line 92, in contribute_to_class
raise TypeError, "'class Meta' got invalid attribute(s): %s" %
','.join(meta_attrs.keys())
TypeError: 'class Meta' got invalid attribute(s): proxy
Error while importing unmanaged_models:  File "./runtests.py", line
134, in django_tests
mod = load_app(model_label)
  File "/var/lib/python-support/python2.6/django/db/models/loading.py",
line 72, in load_app
mod = __import__(app_name, {}, {}, ['models'])
  File "/root/django/tests/modeltests/unmanaged_models/models.py",
line 20, in 
class B01(models.Model):
  File "/var/lib/python-support/python2.6/django/db/models/base.py",
line 55, in __new__
new_class.add_to_class('_meta', Options(meta, **kwargs))
  File "/var/lib/python-support/python2.6/django/db/models/base.py",
line 164, in add_to_class
value.contribute_to_class(cls, name)
  File "/var/lib/python-support/python2.6/django/db/models/options.py",
line 92, in contribute_to_class
raise TypeError, "'class Meta' got invalid attribute(s): %s" %
','.join(meta_attrs.keys())
TypeError: 'class Meta' got invalid attribute(s): managed
Error while importing test_client_regress:  File "./runtests.py", line
134, in django_tests
mod = load_app(model_label)
  File "/var/lib/python-support/python2.6/django/db/models/loading.py",
line 72, in load_app
mod = __import__(app_name, {}, {}, ['models'])
  File "/root/django/tests/regressiontests/test_client_regress/models.py",
line 9, in 
from django.test.utils import ContextList
ImportError: cannot import name ContextList
Error while importing fixtures_regress:  File "./runtests.py", line
134, in django_tests
mod = load_app(model_label)
  File "/var/lib/python-support/python2.6/django/db/models/loading.py",
line 72, in load_app
mod = __import__(app_name, {}, {}, ['models'])
  File "/root/django/tests/regressiontests/fixtures_regress/models.py",
line 72, in 
class WidgetProxy(Widget):
  File "/var/lib/python-support/python2.6/django/db/models/base.py",
line 55, in __new__
new_class.add_to_class('_meta', Options(meta, **kwargs))
  File "/var/lib/python-support/python2.6/django/db/models/base.py",
line 164, in add_to_class
value.contribute_to_class(cls, name)
  File "/var/lib/python-support/python2.6/django/db/models/options.py",
line 92, in contribute_to_class
raise TypeError, "'class Meta' got invalid attribute(s): %s" %
','.join(meta_attrs.keys())
TypeError: 'class Meta' got invalid attribute(s): proxy
Error while importing delete_regress:  File "./runtests.py", line 134,
in django_tests
mod = load_app(model_label)
  File "/var/lib/python-support/python2.6/django/db/models/loading.py",
line 72, in load_app
mod = __import__(app_name, {}, {}, ['models'])
  File "/root/django/tests/regressiontests/delete_regress/models.py",
line 4, in 
from django.test import TransactionTestCase
ImportError: cannot import name TransactionTestCase
Error while importing conditional_processing:  File "./runtests.py",
line 134, in django_tests
mod = load_app(model_label)
  File "/var/lib/python-support/python2.6/django/db/models/loading.py",
line 72, in load_app
mod = __import__(app_name, {}, {}, ['models'])
  File "/root/django/tests/regressiontests/conditional_processing/models.py",
line 6, in 
from django.utils.http import parse_etags, quote_etag
ImportError: cannot import name parse_etags
Traceback (most recent call last):
  File "./runtests.py", line 191, in 
django_tests(int(options.verbosity),