behat-wordpress-extension icon indicating copy to clipboard operation
behat-wordpress-extension copied to clipboard

Database dump is not deleted after test is finish

Open killua99 opened this issue 5 years ago • 5 comments

I'm finding myself delete dump databases after each test run, I thought it would be deleted after each test or having a flag to confirm I want to delete a dump.

The case is, now it generate a dump file each test I run, sometimes you have to run several tests to achieve a feature and more when it has several scenarios.

Would be a good idea, to think about this two options.

One define a database to be the restore point, so we have an option like:

database:
  restore_after_test: true
  backup_path: /path/to/the/dump.sql

That if you give a SQL file will be use for all restores points. But if we have this setting.

database:
  restore_after_test: true
  backup_path: /path/to/store/tmp/database

Is a folder where the test will dump the database and after the test is finish, it will clear the database.

The difference are on, the first one when we give the database file it wont delete it, the second one when is a path that will assume is a tmp dump and it will be deleted after that.

Sorry if this issue is wrong target or so I was seeking for help but it could also be a feature request?

Thanks for this extension btw!

killua99 avatar Dec 19 '18 07:12 killua99

Hi @killua99 Thanks for trying WordHat, and sharing your feedback. I appreciate it!

From the documentation for this setting:

If restore_after_test is true, and the (backup_path) value is a file path, WordHat will use that as the back up to restore the database from. If the path is a directory, then before any tests are run, WordHat will generate a database back up and store it here. If the path has not been set, WordHat will choose its own temporary folder.

So your first suggestion (giving it a SQL dump) should already work. I would recommend this approach for any significant use of WordHat that makes changes to the WordPress site's database, because exporting the database is slow. You'll want to tag any Feature or Scenario that makes a database with the @db annotation, otherwise the DB restore won't be triggered.

If I remember correctly, if WordHat exports the database itself, it does not delete the .sql after the run. We could make a change to have it delete it, what do you think?

I am not keen on clearing the database at the end - what I think you're getting at here is making sure it restores to its initial state (i.e. before WordHat) run, which the current implementation should be doing.

paulgibbs avatar Dec 20 '18 12:12 paulgibbs

Hi @paulgibbs thanks for answering,

Correct idk if I complicated or over wrote what my main point was.

The main point of this is, the dump from temporary database is not been deleted.

Could be good to have an extra option that by default could be something like:

database:
  restore_after_test: true
  backup_path: /path/to/store/tmp/database
  delete_tmp_db: true

The name of it, could be talk later, just throwing ideas.

So is a default value to true, that always delete the tmp_db, how should we know is a tmp db? we don't pass a my-dump-file-33333.sql file, we check we don't pass a sql file, if is just a path, then we will clear the dump after all the test are done.

This could improve maintaining local development clean, I found myself like with 10 dumps on my tmp folder 😊 each dump was close to 80 MB.

The feature of giving a direct dump is awesome, great, but sometimes we need it to be fresh dump, and we don't want to generate a fresh dump each day or so.

So TL:DR Let's build the feature to delete the tmp dump after all test are done. 👍🏽

killua99 avatar Dec 20 '18 13:12 killua99

👍

paulgibbs avatar Dec 20 '18 16:12 paulgibbs

I've been trying to figure out a good way to build this. It's easy-ish to do with the AfterSuite hook and the WP-PHP driver, but harder with WP-CLI (in case of somehow deleting a remote file -- wp eval is probably the solution, but I don't know how it fits into the design of the DatabaseContext, it seems a bit of a kludge).

paulgibbs avatar Apr 11 '19 22:04 paulgibbs

I'll try to give some thought to this too. I didn't leave :)

killua99 avatar Apr 16 '19 16:04 killua99