[ckan-dev] SQLite removal?

[David Read]

> 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

Not running tests often is the traditional programming way. However
many people these days write and run tests frequently. But of course
it's OKF's perogative whether or not they support that or not.

Where tests rely on postgres features then we have skips for running in sqlite.

Dave


On 13 June 2013 23:33, Sean Hammond <sean.hammond at okfn.org> wrote:
> 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
>
> _______________________________________________
> 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