You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 17, 2024. It is now read-only.
Set up knex-db-manager to make it easy to truncate the database from npm scripts. Replace the db:clean job that is currently relying on migrations with truncating the DB. Alter the test that is using db:clean to test the it is possible to migrate down to use knex db:migrate down instead.
Reason being that while developing migrations locally, you can easily end up in an inconsistent state (your up and down migrations did not actually match) so the recommended practice is to truncate before each run locally.
What would be the best approach to do testing with knex? I understand that the knex-manager can clear the database on each setup and teardown, but what about the time penalty after say a 100 tests using this approach. You could create stubs to replace the db, but it wouldn't be the same.
Set up knex-db-manager to make it easy to truncate the database from npm scripts. Replace the
db:clean
job that is currently relying on migrations with truncating the DB. Alter the test that is usingdb:clean
to test the it is possible to migrate down to useknex db:migrate down
instead.Reason being that while developing migrations locally, you can easily end up in an inconsistent state (your up and down migrations did not actually match) so the recommended practice is to truncate before each run locally.
https://github.com/Vincit/knex-db-manager
The text was updated successfully, but these errors were encountered: