TransactionManagementError "You can't execute queries until the end of the 'atomic' block" while using signals, but only during Unit Testing

Since @mkoistinen never made their comment an answer, I'll post the suggestion so people won't have to dig through comments.

consider just declaring your test class as a TransactionTestCase rather than just TestCase.

From the Django docs: A TransactionTestCase may call commit and rollback and observe the effects of these calls on the database.

If using pytest-django you can pass transaction=True to the django_db decorator to avoid this error.

See https://pytest-django.readthedocs.io/en/latest/database.html#testing-transactions

Django itself has the TransactionTestCase which allows you to test transactions and will flush the database between tests to isolate them. The downside of this is that these tests are much slower to set up due to the required flushing of the database. pytest-django also supports this style of tests, which you can select using an argument to the django_db mark:

@pytest.mark.django_db(transaction=True) def test_spam(): pass # test relying on transactions 

Here is another way to do it, based on the answer to this question:

with transaction.atomic(): self.assertRaises(IntegrityError, models.Question.objects.create, **{'domain':self.domain, 'slug':'barks'}) 

In my case it was caused but not calling super().tearDownClass()

class TnsFileViewSetTestCase(APITestCase): @classmethod def tearDownClass(self): super().tearDownClass() # without this line we will get TransactionManagementError for tnsfile in TnsFile.objects.all(): tnsfile.file.delete() 

I have the same issue, but with transaction.atomic() and TransactionTestCase didn't work for me.

python manage.py test -r instead of python manage.py test is ok for me, maybe the order of execution is crucial

then i find a doc about Order in which tests are executed, It mentions which test will run first.

So, I use TestCase for database interaction, unittest.TestCase for other simple test, it works now!

class Pricing(models.Model): price = models.DecimalField(max_digits=4, decimal_places=1) is_active = models.BooleanField(default=False) def __str__(self): return str(self.price) class Services(models.Model): name = models.CharField(max_length=30) description = models.CharField(max_length=30) pricing = models.OneToOneField(Pricing, on_delete=models.CASCADE, default=0.0) categories = models.ManyToManyField(Category, related_name="services") is_active = models.BooleanField(default=False) def __str__(self): return self.name 

In my case you are getting this error in the function where you are testing an instance onetoonefield : where you're creating a price instance and adding it into 2 service instances and getting this error:

Solution : Inside your function do this

with transaction.atomic(): with self.assertRaises(IntegrityError): service = Services.objects.create(name = "Some Service", pricing= self.pricing1) 

For me, the proposed fixes did not work. In my tests, I open some subprocesses with Popen to analyze/lint migrations (e.g. one test checks if there are no model changes).

For me, subclassing from SimpleTestCase instead of TestCase did do the trick.

Note that SimpleTestCase doesn't allow to use the database.

While this does not answer the original question, I hope this helps some people anyway.

def test_wrong_user_country_db_constraint(self): """ Check whether or not DB constraint doesnt allow to save wrong country code in DB. """ self.test_user_data['user_country'] = 'XX' expected_constraint_name = "country_code_within_list_of_countries_check" with transaction.atomic(): with self.assertRaisesRegex(IntegrityError, expected_constraint_name) as cm: get_user_model().objects.create_user(**self.test_user_data) self.assertFalse( get_user_model().objects.filter(email=self.test_user_data['email']).exists() ) 

with transaction.atomic() seems do the job correct 

If you wanna perform multiple queries, this is the way to do it

@pytest.mark.django_db def test_multiple queries_where_one_fails(): # Double transaction wrap is needed with transaction.atomic(): # do a process with some failing query with transaction.atomic(): assert Model.objects.count() == 0 # rest of assertions 

I was getting this error on running unit tests in my create_test_data function using django 1.9.7. It worked in earlier versions of django.

It looked like this:

cls.localauth,_ = Organisation.objects.get_or_create(organisation_type=cls.orgtypeLA, name='LA for test', email_general='[email protected]', address='test', postcode='test', telephone='test') cls.chamber,_ = Organisation.objects.get_or_create(organisation_type=cls.orgtypeC, name='chamber for test', email_general='[email protected]', address='test', postcode='test', telephone='test') cls.lawfirm,_ = Organisation.objects.get_or_create(organisation_type=cls.orgtypeL, name='lawfirm for test', email_general='[email protected]', address='test', postcode='test', telephone='test') cls.chamber.active = True cls.chamber.save() cls.localauth.active = True cls.localauth.save() <---- error here cls.lawfirm.active = True cls.lawfirm.save() 

My solution was to use update_or_create instead:

cls.localauth,_ = Organisation.objects.update_or_create(organisation_type=cls.orgtypeLA, name='LA for test', email_general='[email protected]', address='test', postcode='test', telephone='test', defaults={'active': True}) cls.chamber,_ = Organisation.objects.update_or_create(organisation_type=cls.orgtypeC, name='chamber for test', email_general='[email protected]', address='test', postcode='test', telephone='test', defaults={'active': True}) cls.lawfirm,_ = Organisation.objects.update_or_create(organisation_type=cls.orgtypeL, name='lawfirm for test', email_general='[email protected]', address='test', postcode='test', telephone='test', defaults={'active': True}) 

The answer of @kdazzle is correct. I didnt try it because people said that 'Django’s TestCase class is a more commonly used subclass of TransactionTestCase' so I thought it was the same use one or another. But the blog of Jahongir Rahmonov explained it better:

the TestCase class wraps the tests within two nested atomic() blocks: one for the whole class and one for each test. This is where TransactionTestCase should be used. It does not wrap the tests with atomic() block and thus you can test your special methods that require a transaction without any problem.

EDIT: It didn't work, I thought yes, but NO.

In 4 years they could fixed this.......................................

I had the same issue.

In My Case I was doing this

author.tasks.add(tasks) 

so converting it to

author.tasks.add(*tasks) 

Removed that error.