id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
31612	Running tests with --keepdb messy to flush.	Jarek Glowacki	nobody	"We run tests with `--keepdb` flag by default. If there are changes that require dropping the test database, we run the testsuite once without the keepdb flag.
However this not only drops the db before tests, but also drops it after tests too.
So next time we run the testsuite with the --keepdb flag, the database is recreated and migrations are run once more (unnecessarily).

It feels very clunky.

It all works as initially intended in https://code.djangoproject.com/ticket/20550:
> I'd like to implement a similar feature in Django. In the light of my first experience, I suggest a simpler API. I would add a single flag --keepdb. When this flag is set:
> - at the beginning of the tests, if the database already exists, Django doesn't ask to delete it; it goes ahead and reuses it;
> - at the end of the tests, Django doesn't drop the database.

The original ticket author mentioned they'd implemented the `--nocreatedb` and `--nodropdb` options in their own project, prior to `--keepdb` existing, so they didn't have this issue.
I like the simplification that django offers and am not proposing to split keepdb into two separate flags, however offering a flag that enables either of the following would greatly unclunk `--keepdb`s use:
- ""Don't drop db after running tests."" (when `--keepdb` is off). Something like `--preservedb`, `--nodropdb`, etc.
- ""Drop db prior to running tests."" (when `--keepdb` is on). Something like `--refreshdb`, etc.

Yes, it's an extra flag, but it doesn't work the same way as `--nocreatedb` and `--nodropdb`, because for the majority of runs users just need to pass one flag (`--keepdb`), rather than multiple.

Another solution could be to offer a separate mcommand called `droptestdb` or something similar -- it's sole role would be to clean up anything that was left by the last `--keepdb`, so that the next one can run with a fresh db.

Finally, changing behaviour on `--keepdb` so that it somehow _knows_ when to prompt to start from scratch when it feels there is something not lining up in the migrations could be another way to go. Solution would be very magic, and maybe not great at guessing when to prompt, but would save the user from having to learn any of the other proposed options.

In short, `--keepdb` is flawed in how it requires TWO rounds of dropping/creating the db and running migrations (running without keepdb, then with keepdb again) to refresh a database.
I've put forward a few ideas on how to address this, but none particularly compelling.

Any thoughts?"	New feature	closed	Testing framework	dev	Normal	wontfix	test keepdb	frnhr	Unreviewed	0	0	0	0	0	0