Switch unit tests to using in-memory sqlite databases

[Christopher Allan Webber]

At the moment, running tests that don't use a full mediagoblin app are fast, ones that do are slow. Probably the reason for this is that we use 3 sqlite databases (one for celery, one for Kombu, one for mediagoblin itself).

I'm not sure whether the celery of kombu (which isn't used during tests anyway) databases would be affected by unit tests if we just switched them over to an in-memory database. It might be easy enough to just do those and they'd be just fine. I don't know.

MediaGoblin's db is a bit different because it needs to run the migration machinery to init the db. This means that things will be a bit tricky: Somehow we need to create a reference to the database *before* the MediaGoblin application spins up and connects it to the ORM. Then we need to pass that database connection (without the ORM initialized) to the migrations, then pass it into the MediaGoblin application, which must then connect the ORM to the database based on init.

Problem: we set up MediaGoblin's application wrapped in paste, so we don't have much control over this.

Here's an alternate solution, also evil, maybe even more so: MediaGoblin the application itself could contain a config option where it will, on init, run dbupdate from *within itself* if needed. (Note: that *could* be used in production environments also but I think it would more likely than not, especially if a person is both running MediaGoblin *and* celery, shoot us in the foot.)

[Emily O'Leary]

I've implemented this in the following commit:

​https://gitorious.org/~lotusecho/mediagoblin/lotusechos-mediagoblin/commit/4a698535bc97b37c8eb42ffea2cc3e7bd48565e6

I had it check for a run_migrations configuration option and if it was set to true (default is false) then it runs the run_all_migrations function which was part of the old dbupdate function. I moved that functionality to this new function and simply called it from within dbupdate as to facilitate code reuse.

Now with these config changes in place tests take approximately one minute to run all 103 current tests on my machine versus before where it would take approximately six minutes to complete them all.

[Christopher Allan Webber]

This is really great. The speed difference here is huge! I have a few comments, but already this is really useful:

• Thanks for writing a docstring on run_all_migrations. It sounds a bit like a commit message though since it explained what you did rather than what the function does?
• It's good to wrap text at 80 characters. This greatly enhances readability (terminals in general don't go farther than this, and the human eye does an easier job "scanning down", and long lines prevent this... 80 characters is around "book page length")
  • Not going to make you redo the commit, but in the pfuture, please do try to wrap the commit comment at the 80th column.
  • Similarly, the config_spec.ini comment should wrap.
• Could you add a comment to config_spec.ini explaining that this is for testing only, and we do not recommend users turn it on their own instances?
• Lastly, I wonder if there would be a speedup if we switch the celery/kombu database lines over. That would be the CELERY_RESULT_DBURI and BROKER_HOST lines in the [celery] section of the config. However I just tested it and noticed no difference... oh well ;)

Thanks, Emma! Looking forward to merging this!

[Emily O'Leary]

I altered the comments based on your suggestions. See the feature branch: ​https://gitorious.org/~lotusecho/mediagoblin/lotusechos-mediagoblin/commits/trac_711_test_speed

[Christopher Allan Webber]

Awesome. I merged it! Great work!