#31612: Running tests with --keepdb messy to flush.
               Reporter:  Jarek Glowacki     |          Owner:  nobody
                   Type:  Uncategorized      |         Status:  new
              Component:  Testing framework  |        Version:  3.0
               Severity:  Normal             |       Keywords:  test keepdb
           Triage Stage:  Unreviewed         |      Has patch:  0
    Needs documentation:  0                  |    Needs tests:  0
Patch needs improvement:  0                  |  Easy pickings:  0
                  UI/UX:  0                  |
 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
 > 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

 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

 Any thoughts?

Ticket URL: <https://code.djangoproject.com/ticket/31612>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to