Smoke test for migrations

[timdiggins]

Given #436 and similar...

I think it would be good to have a spec that can at least ensure that a given migration basically works: given a v0.7 sample sqlite file, we can run the migration. Could do more complex specs on this (cross db, specific checks) but a basic smoke test that the migration doesn't blow up would be v helpful.

Am working on this (mechanism to create a simple sample set in v0.x and then add it, and then a simple spec to test this (sqlite only, initially))

[jayroh]

This is not only a great idea for this project but for all rails apps in
general. Tim this would make for an excellent ruby gem.

I can't tell you how many projects I've parachuted in on that had
completely busted migrations due to one or more bad practices.

On Thu, Oct 27, 2016 at 9:05 AM, Tim Diggins notifications@github.com
wrote:

Given #436 #436 and similar...

I think it would be good to have a spec that can at least ensure that a
given migration basically works: given a v0.7 sample sqlite file, we can
run the migration. Could do more complex specs on this (cross db, specific
checks) but a basic smoke test that the migration doesn't blow up would be
v helpful.

Am working on this (mechanism to create a simple sample set in v0.x and
then add it, and then a simple spec to test this (sqlite only, initially))

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#437, or mute the thread
https://github.com/notifications/unsubscribe-auth/AABuIrjB7g3LrvKuJ-BrcsqSi7Tl6xzTks5q4KGrgaJpZM4KiUyg
.

[timdiggins]

@jayroh not sure my solution will be that general purpose to be exportable as a gem -- but having some working practice seems like a good idea. I've started a version using an sqlite file in the repo, but I think I'm going to switch to using a (still sqlite-specific) dump file and a restore command. This way (a) we can have more than just one smoke test (as there's a possible db-clean approach) and (b) can (eventually) support mysql/postgresql dbs. However it can't see a way out of requiring this to have a totally separate rspec run, as otherwise it requires us to reload Rails totally from within the spec run, which feels dubious.

Also we should then as the first commit after a new minor-level release create new sample data + migration spec for the release and ditch the old sample data and migration spec (because there's no point in testing that say v0_6=>v0_7 migration works in v0.8.0 -- the answer is to checkout v0.7.0 and run it there.) Am trying to create instructions & tooling to help this.

In the meantime I'm using my branch to sanity test the migrations we're writing for Customizable Notifiers (#441)