[ckan-dev] SQLite removal?

Fri Jun 14 14:15:01 UTC 2013

> > Right, I'll often run the specific test modules that the code I'm
> working on affects frequently as I'm developing, but only run the whole
> test suite at the end before merging to master (if at all, Travis will
> often have run it for me).
> 
> Great, you're finally addressing the situation that I'm talking about
> (I'm in agreement about not running the full tests - leave it to
> Travis).
> 
> As per my example, postgres takes 12s versus sqlite 3s for running a
> couple of simple tests - the ones relevant to the code currently being
> written. As you add a couple of lines of code and add a new assert to
> the test in parallel with the feature, you'll find yourself running
> the relevant tests several times a minute. Waiting 12s for them to run
> each time and you simply break your flow.

I'm not convinced about this. You're telling me that the unit tests for
one module takes 12s to run with postgres and 3s with sqlite? And this
isn't because either the tests or the ckan module is badly designed?

Anyway, from my point of view, there should only be one way of running
the tests and it should be fast. As discussed introducing "run the tests
with postgres" and "run the same tests, but with sqlite" creates various
problems. I think the right way to do this might be to write more
testable code that's easier and faster to test in the first place, and
then write better and faster tests for it.

For example, rather than either running all the tests with postgres and
then having a different command to run all the tests with sqlite
instead, a particular CKAN module that uses the database should accept a
database object as parameter, in normal operation it would be passed a
postgres database object but the tests could pass it an in-memory sqlite
database object instead.

If we used this approach throughout then you would have just one command
"run the tests" and each test would use either a postgres database
(when really necessary) or a faster sqlite one whenever possible.
Hopefully the tests overall would be pretty fast, and running the tests
for most individual modules would be very fast and not touch the disk at
all. And no problem with having two separate ways of running the tests.