Are scenarios run in a database transaction?

[behave]

Are scenarios run in a database transaction?

[JCapriotti]

Yep, sorry I forgot to reply earlier; I saw a shiny object that day.

It is good to close.

[bittner]

Answer 1: Yes, behave-django is using LiveServerTestCase. There are no changes remaining in tables after a test scenario is completed, because of the inner workings of TransactionTestCase.

Answer 2: I can only imagine adding reset_sequences = True to our BehaviorDrivenTestCase (maybe in BehaviorDrivenTestRunner) by default. Should be doable to even make this configurable.

[JCapriotti]

FWIW, I have a workaround, which also (I think) validates my assessment above.

from behave_django.testcase import BehaviorDrivenTestCase
from django.test import TransactionTestCase

old_test_case_init = BehaviorDrivenTestCase.__init__

def new_test_case_init(self, *k, **kw):
    old_test_case_init(self, *k, **kw)
    TransactionTestCase.reset_sequences = True

BehaviorDrivenTestCase.__init__ = new_test_case_init

[JCapriotti]

Re: Answer 2... I can look into making it configurable

[bittner]

Adding this (configurable) feature is certainly a sweet addition to behave-django. Apart from that I guess you're probably doing something in your tests that is discouraged to do. The documentation says:

Unless you are explicitly testing primary keys sequence numbers, it is recommended that you do not hard code primary key values in tests.

In other words: You should not test on primary key values. -- There must be a better way.

Also, a reason to not include reset_sequences = True by default in our TestCase:

Using reset_sequences = True will slow down the test, since the primary key reset is an relatively expensive database operation.

[bittner]

@JCapriotti is this still an issue you feel worth to be fixed? Can you contribute the necessary changes and place a pull request?

[bittner]

I'm closing this due to lack of activity / interest. Please feel free to reopen this again any time.

[bittner]

Shiny object? Not sure what you're referring to. Want to elaborate?

[ckcollab]

(I just arrived here from Google, but I think @JCapriotti is saying he got distracted by a shiny obj---oh, look a squirrel!)

[kwiliarty]

@JCapriotti 's workaround also proves helpful if you need to set serialized_rollback = True for your test cases.

I was having a problem where data migrations that are part of the main site set-up were being wiped after the first scenario. There's a good description of that problem here:

https://stackoverflow.com/questions/26273921/django-1-7-testing-losing-data-from-data-migration

The serialized_rollback workaround to that problem is suggested here:

https://code.djangoproject.com/ticket/23640

But I couldn't figure out how to add it to the test case until reading this thread. So if anyone else ends up here looking for the same, I found that adding this to the environment.py file worked:

from behave_django.testcase import BehaviorDrivenTestCase
from django.test import TransactionTestCase


old_test_case_init = BehaviorDrivenTestCase.__init__


def new_test_case_init(self, *k, **kw):
    old_test_case_init(self, *k, **kw)
    TransactionTestCase.serialized_rollback = True


BehaviorDrivenTestCase.__init__ = new_test_case_init

[bittner]

As mentioned by a friendly user in our Gitter chat room a solution approach may be to set serialized_rollback = True on the testcase.

See also

• https://kevinwiliarty.com/posts/behave-django-monkey-patches/
• https://docs.djangoproject.com/en/stable/topics/testing/overview/#rollback-emulation