Are scenarios run in a database transaction?

[JCapriotti]

Hello,
I have some test cases that appear to be failing because of how the database is reset after each scenario. Specifically, database sequences are not being reset. I stumbled on what seems like conflicting statements in the documentation.

From https://pythonhosted.org/behave-django/usage.html#database-transactions-per-scenario

Each scenario is run inside a database transaction, just like your regular TestCases

From the last paragraph of https://pythonhosted.org/behave-django/usage.html#fixture-loading

This is because Django’s LiveServerTestCase resets the test database after each scenario

Now if you dig into LiveServerTestCase via https://docs.djangoproject.com/en/1.9/topics/testing/tools/...

LiveServerTestCase does basically the same as TransactionTestCase

Or, LiveServerTestCase is a subclass of TransactionTestCase. And further down...

• A TransactionTestCase resets the database after the test runs by truncating all tables. A TransactionTestCase may call commit and rollback and observe the effects of these calls on the database.
• A TestCase, on the other hand, does not truncate tables after a test. Instead, it encloses the test code in a database transaction that is rolled back at the end of the test. This guarantees that the rollback at the end of the test restores the database to its initial state.

My first question is... is it correct that that behave-django is using a LiveServerTestCase, which means there is no database transaction happening?

Second, is there any way to change what happens when the database is reset? i.e. specify that the TestCase transaction behavior be used. Or alternatively, allow support modifying things like TransactionTestCase.reset_sequences

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

[JCapriotti]

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

It is good to close.

[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