[ckan-dev] SQLite removal?

[Sean Hammond]

Having Travis run the tests for us has really reduced the amount of
times devs need to run them on their laptops.

You still need to sometimes, of course.

I'd argue that the real fix for this is to write a better and faster
test suite. Have more unit tests and not as many functional tests, unit
tests are faster because they just import a module and tests its
functions directly, instead of testing the whole application stack.
Avoid unnecessarily hitting the disk, network or database in tests.
And let each test just run the setup code that it needs, instead of
having large, generic text fixtures (create_test_data) that get run
again and again.

Also, making CKAN faster will make the tests faster.

Of course this is a (very) long-term approach, sqlite is a quick gain.

I think the problem with sqlite is we're starting to get maintenance
costs. People are introducing code that works with postgres but fails
with sqlite (and not realizing because they don't run the sqlite tests).
People are adding code that uses postgres features that sqlite doesn't
support.

We'd have to get Travis to run the sqlite tests as well, if we want to
make sure they keep working. And Travis already runs the tests four
times for every commit with different versions of Python and Postgres.

On Wed, Jun 12, 2013 at 02:53:17PM +0100, David Read wrote:
> sqlite tests were introduced purely for speed. Running all tests was
> taking over 10 minutes, putting developers off running them. We even
> had people starting to ruthlessly disable reams of key tests to make
> them faster! With a tuned sqlite we got it down to 1 minute for all
> tests - about 400 at the time I think.
> 
> I use sqlite still for CKAN tests all the time. I think most of the
> new developers simply haven't given it a try, so here's my pitch:
> 
> sqlite is perfect for TDD or anything approaching it, since the
> code-test turn-around time of a few tests is far quicker. In the
> example below, running 3 tiny tests takes 3s with sqlite and 12s with
> postgres.
> 
> Or maybe people have found another way to run a test in a couple of seconds?
> 
> David
> 
> (pyenv-ckan)dread at dthink:~/gitroot/ckan$ time nosetests --ckan
> --with-pylons=test-core.ini ckan/tests/lib/test_munge.py
> ...
> ----------------------------------------------------------------------
> Ran 3 tests in 8.940s
> 
> OK
> 
> real 0m11.963s
> user 0m6.060s
> sys 0m0.720s
> (pyenv-ckan)dread at dthink:~/gitroot/ckan$ time nosetests --ckan
> --with-pylons=test.ini ckan/tests/lib/test_munge.py
> ...
> ----------------------------------------------------------------------
> Ran 3 tests in 0.365s
> 
> OK
> 
> real 0m3.282s
> user 0m2.852s
> sys 0m0.384s
> (pyenv-ckan)dread at dthink:~/gitroot/ckan$
> 
> On 12 June 2013 08:53, Hendrik Bunke <bunke.hendrik at gmail.com> wrote:
> > Personally I love using SQLite for developing and testing
> > purposes. Postgresql is kind of overkill for such cases. So I'd
> > vote for leaving it in.
> >
> > regards
> > hendrik
> >
> > --On 2013-06-11 14:19, Toby Dacre wrote:
> >> As I understand it we can use SQLite for the tests (for some
> >> performance benefits)
> >>
> >> There are also some issues regarding SQLite being broken
> >>
> >> Is this something that we should continue to support?  I am not sure
> >> the extra maintenance is worth it - what do people think?
> >>
> >> If so shall we do this in 2.2
> >>
> >
> > --
> > Dr. Hendrik Bunke
> > http://gplus.to/hbunke
> > http://twitter.com/hbunke
> > http://www.hbxt.org
> >
> > _______________________________________________
> > ckan-dev mailing list
> > ckan-dev at lists.okfn.org
> > http://lists.okfn.org/mailman/listinfo/ckan-dev
> > Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
> 
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev