When testing django apps, my unit test usually accesses the django app via django test client: https://docs.djangoproject.com/en/3.0/topics/testing/tools/#the-test-client. Django test client simulates http access, so my Django tests always run my Django code starting from Django views. Even though there must be many django app code that has `transaction.atomic` inside it, I never need to add `transaction.atomic` in my unit test code. If I need to simulate initial state by having some data inserted to database, I did that either using factoryboy or django ORM framework, but I see no point to add `transaction.atomic` to that data initialization code.
On Tue, May 12, 2020 at 12:39 PM Uri Kogan <[email protected]> wrote: > While this can be done in my code, there are libraries that the project > use that have "transaction.atomic" in them. For example, pretty popular > django-role-permissions. > From what I see in the documentation, there should be no problem to use > transactions within transactions in TestCase. > > On Tuesday, May 12, 2020 at 12:34:50 AM UTC+3, Aldian Fazrihady wrote: >> >> I don't think the subclass of TestCase need to use transaction.atomic. >> Why can't you just remove the transaction.atomic? >> >> Regards, >> >> Aldian Fazrihady >> http://aldianfazrihady.com >> >> Pada tanggal Sel, 12 Mei 2020 04.02, Uri Kogan <[email protected]> >> menulis: >> >>> Hello, >>> >>> I am using TestCase and trying to create an object during test. >>> There is a log activated on MySQL server, so I see all the queries being >>> executed there. >>> >>> This "transaction.atomic" sets a SAVEPOINT in the database thinking that >>> the transaction is already started. The problem is that there is no >>> "TRANSACTION START". So, when exiting "with transaction.atomic()" block the >>> whole thing crashes with "SAVEPOINT xxx DOES NOT EXIST" >>> >>> The following states that TestCase "tests within two nested atomic() >>> blocks", so it should execute "TRANSACTION START" >>> >>> https://docs.djangoproject.com/en/3.0/topics/testing/tools/#django.test.TestCase >>> >>> >>> from django.contrib.auth.models import User >>> from django.test import TestCase >>> >>> >>> class FooTest(TestCase): >>> def test_bar(self): >>> with transaction.atomic(): >>> user = User.objects.create_user(username="abc", >>> password="pass") >>> >>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-users/ecff11bd-9d35-4130-9d3a-0d48f70af73f%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-users/ecff11bd-9d35-4130-9d3a-0d48f70af73f%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/3741328a-941b-4864-a20d-5e2d9c4937d5%40googlegroups.com > <https://groups.google.com/d/msgid/django-users/3741328a-941b-4864-a20d-5e2d9c4937d5%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Regards, Aldian Fazrihady http://aldianfazrihady.com -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAN7EoAYO3N3E7Jrds9sqmnfKOUFHwtdf%3DXMra2WZ3WCiDiJfEw%40mail.gmail.com.
