Re: No ROLLBACK within TestCase on second database

[Mike Dewhirst]

On 5/09/2012 3:09pm, Kit Randel wrote:

On 05/09/12 16:28, Mike Dewhirst wrote:

I asked about this a couple of weeks ago and the correct solution is
to use a TransactionTestCase


Hi Mike,

I don't want to be explicitly test transactional behaviour, which I
think is the intention behind TransactionTestCase. I just want each test
running a transaction which rolls back on teardown. The django
documentation for TestCase seems to suggest that TestCase should provide
the behaviour I'm wanting:

/class/TestCase
Wraps each test in a transaction.

https://docs.djangoproject.com/en/dev/topics/testing/#testcase


In your earlier post you mention Django 1.2 but the reference you quote 
above is the dev documentation. There are differences in the docs but 
I'm not sure what the underlying code differences might be.


You are right though. If you want to test commits and rollbacks 
TransactionTestCase is your thing. By my reading of both 1.2 and dev 
docs, vanilla TestCase imported from Django on the other hand should 
handle commits and rollbacks itself.


As to your second database, I can't help because I have zero experience 
with multiple databases. However, I think I have recently seen a caveat 
in the docs somewhere about testing with multiple database. I haven't 
looked in the 1.2 docs for some time.


Mike


Explicitly calling connection._rollback() in a TransactionTestCase
unfortunately has the same behaviour and only calls ROLLBACK on the
'default' database.



--
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: No ROLLBACK within TestCase on second database

[Kit Randel]

On 05/09/12 16:28, Mike Dewhirst wrote:
I asked about this a couple of weeks ago and the correct solution is to use a 
TransactionTestCase

Hi Mike,

I don't want to be explicitly test transactional behaviour, which I think is 
the intention behind TransactionTestCase. I just want each test running a 
transaction which rolls back on teardown. The django documentation for TestCase 
seems to suggest that TestCase should provide the behaviour I'm wanting:

class TestCase
Wraps each test in a transaction.

https://docs.djangoproject.com/en/dev/topics/testing/#testcase

Explicitly calling connection._rollback() in a TransactionTestCase 
unfortunately has the same behaviour and only calls ROLLBACK on the 'default' 
database.

-- 
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: No ROLLBACK within TestCase on second database

[Mike Dewhirst]

On 5/09/2012 12:01pm, Kit Randel wrote:

Hi there,

I'm running into an issue on Django 1.2 where the second test in my test
suite fails due to a duplicate key value violation. It appears that the
issue is that calls to my 'default' db, test_app_django in this case,
run within a transaction, but those to my application db, test_app, do
not. You can see from the SQL log that only the default db has a
ROLLBACK, causing later tests to fail. Does anyone know how I can ensure
that interaction with my second db is also run within a transaction and
appropriately rolled back?


I asked about this a couple of weeks ago and the correct solution is to 
use a TransactionTestCase


https://groups.google.com/forum/?fromgroups=#!topic/django-users/RxzVIqQINq8

Mike




test_member_programme.py
--
from datetime import date, timedelta

from django.test import TestCase

from fred_db.test.factories import StudentFactory, ProgrammeFactory
from fred_db.models import StudentProgramme

class StudentProgrammeTestCase(TestCase):

 def setUp(self):
 self.stud_prg = self.student_programme()

 def tearDown(self):
 pass

 def student_programme(self):
 yesterday = date.today() - timedelta(days=1)
 return StudentProgramme.objects.create(
 stud=StudentFactory(),
 prgm=ProgrammeFactory(),
 date_registered=yesterday)

 def date_registered_should_be_defined_test(self):
 assert hasattr(self.stud_prg, 'date_registered')

 def date_registered_should_be_in_past_test(self):
 assert self.stud_prg.date_registered < date.today()
-

|dba test_app127.0.0.1  2012-09-04  21:51:50.806  UTC LOG:   duration:  0.038  
ms  statement:  BEGIN;  SET TRANSACTION ISOLATION LEVEL READ COMMITTED
dba test_app127.0.0.1
2012-09-04  21:51:50.808  UTC LOG:   duration:  0.903  ms  statement:  INSERT INTO"member_programme"  ("mem_id",  
"prgm_id",  "date_registered",  "date_completed",  "ordinality")  VALUES(1,  1,  E'2012-09-04',  
NULL,  1)
dba test_app127.0.0.1
2012-09-04  21:51:50.808  UTC LOG:   duration:  0.150  ms  statement:  SELECT 
CURRVAL(pg_get_serial_sequence('"member_programme"','id'))
dba test_app127.0.0.1
2012-09-04  21:51:50.810  UTC LOG:   duration:  1.796  ms  statement:  COMMIT
dba test_app_django127.0.0.1  2012-09-<
span class="lit" style="margin: 0px; padding: 0px; border: 0px; font-size: 14px; 
vertical-align: baseline; background-color: transparent; color: rgb(128, 0, 0); background-position: 
initial initial; background-repeat: initial initial; ">04  21:51:50.811  UTC LOG:   duration:  
0.056  ms  statement:  ROLLBACK<  ROLLBACK ON DJANGO DB ONLY
dba test_app_django127.0.0.1  2012-09-<
span class="lit" style="margin: 0px; padding: 0px; border: 0px; font-size: 14px; 
vertical-align: baseline; background-color: transparent; color: rgb(128, 0, 0); background-position: 
initial initial; background-repeat: initial initial; ">04  21:51:50.814  UTC LOG:   
disconnection:  session time:  0:00:21.005  user=dba database=test_app_django host=127.0.0.1  
port=60355
dba test_app127.0.0.1
2012-09-04  21:51:50.818  UTC LOG:   disconnection:  session time:  0:00:04.751 
 user=dba database=test_app host=127.0.0.1  port=60357
dba test_app127.0.0.1
2012-09-04  21:54:00.796  UTC LOG:   connection authorized:  user=dba 
database=test_app
dba test_app127.0.0.1
2012-09-04  21:54:00.802  UTC LOG:   duration:  0.243  ms  statement:  SET 
DATESTYLE TO'ISO'
dba test_app127.0.0.1
2012-09-04  21:54:00.802  UTC LOG:   duration:  0.156  ms  statement:  SHOW 
client_encoding
dba test_app127.0.0.1
2012-09-04  21:54:00.803  UTC LOG:   duration:  0.047  ms  statement:  SHOW 
default_transaction_isolation
dba test_app127.0.0.1
2012-09-04  21:54:00.803  UTC LOG:   duration:  0.068  ms  statement:  BEGIN;  
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
dba test_app127.0.0.1
2012-09-04  21:54:00.804  UTC LOG:   duration:  0.410  ms  statement:  SET TIME 
ZONE E'Pacific/Auckland'
dba test_app127.0.0.1
2012-09-04  21:54:00.805  UTC ERROR:   duplicate key value violates unique 
constraint"country_of_origin_code_key"|


Many thanks!

--
Bayard 'Kit' Randel / Software Developer
Faculty of Medicine, University of Otago

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