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 <urk...@gmail.com> 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 <urk...@gmail.com> >> 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 django...@googlegroups.com. >>> 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 django-users+unsubscr...@googlegroups.com. > 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 django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAN7EoAYO3N3E7Jrds9sqmnfKOUFHwtdf%3DXMra2WZ3WCiDiJfEw%40mail.gmail.com.
