The equivalent of LETTUCE_USE_TEST_DATABASE

[ramast]

Test cases tend to be extremely slow when destroying and create new DB after each feature (postgres).
We use LETTUCE_USE_TEST_DATABASE = False in lettuce to prevent the continuous destruction/creation and use hooks to clear the DB tables after each scenario.

How do I achieve same thing with Aloe?
Right now I keep getting

Creating test database for alias 'default'...
Type 'yes' if you would like to try deleting the test database 'test_app_test', or 'no' to cancel: Got an error creating the test database: database "test_app_test" already exists

[koterpillar]

I can't reproduce this behavior, here's the example output with two features being run:

$ ./manage.py harvest -v 2
nosetests -v --verbosity=2
Creating test database for alias 'default' ('file:memorydb_default?mode=memory&cache=shared')...
Operations to perform:
  Synchronize unmigrated apps: aloe_django, messages, staticfiles
  Apply all migrations: admin, auth, contenttypes, sessions
Synchronizing apps without migrations:
  Creating tables...
    Running deferred SQL...
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying sessions.0001_initial... OK
View page (exampleapp.features.hello: Hello World) ... ok
View page (exampleapp.features.hello2: Hello World) ... ok

----------------------------------------------------------------------
Ran 2 tests in 1.147s

OK
Destroying test database for alias 'default' ('file:memorydb_default?mode=memory&cache=shared')...

As you can see, the test database is only created and destroyed once. Are you sure there's no hooks that try to flush the database or do anything else to it?

[ramast]

Yes, you are right. I wasn't accurate in my original post.
I wanted to disable the database creation/deletion all together because its a time consuming process when u have so many migration files.
LETTUCE_USE_TEST_DATABASE flag in lettuce cause the engine to use the test DB instead of creating / destroying its DB.

I've overcame that by subclassing the test runner and override setup_databases and teardown_databases to make them do nothing.

That solved the problem for me but I feel it would've been nicer if that settings flag is supported here to keep same behavior as lettuce

[koterpillar]

Using the development database for tests is bad practice and will not be supported, as the tests must run from a clean state. You can try --keepdb (but see #47).

[ramast]

I agree that tests must be run from a clean state, in fact in our case each feature file must be run in clean state (with whole DB empty).
Unfortunately we can't do that by dropping/creating DB after each feature because of the time it takes so we revert to resetting all DB tables after each run.

I've solved the problem by inheriting from TestRunner so I am fine if this ticket will be closed, just stating why people might not want to teardown their DB

[koterpillar]

I know too well that the database creation can take a long time, this is why --keepdb exists.

I'll check that LETTUCE_USE_TEST_DATABASE is mentioned in the porting docs.