On Mon, Sep 16, 2013 at 2:38 PM, Peter Cock <p.j.a.c...@googlemail.com> wrote:
> On Mon, Sep 16, 2013 at 2:30 PM, Dave Bouvier <d...@bx.psu.edu> wrote:
>> Peter,
>> Yes, the functional test suite is a bit on the slow side, and one of my
>> long-term goals has been to improve the performance as best I can.
>> ...
>>> Perhaps the empty SQLite database could even be
>>> cached in BitBucket too, for a faster first test run with
>>> a clean checkout?
>> I'm not sure of that idea, it would feel a bit like adding a
>> non-essential file to the codebase which is generated
>> programmatically by existing code.
> External caching would be enough (and cleaner).

Hi Dave,

I've tried using GALAXY_TEST_DBURI this way with a ready
made SQLite database using the current schema (version 117),
and it seems to work fine within my TravisCI tool testing [*],
and does seem to made things a little faster.


>From that TravisCI build, the pre-test parts of the
functional_tests.py now take about 16s, which is OK
(but still frustratingly slow if testing a single tool).

In fact, out of the entire TravisCI run time of 14m35s, the
setup overhead is now only about 1m30s, it is running the
tests which is slow (about 13 minutes). So that seems the
best place to focus, e.g. John's idea to switch from faking
the HTML controls with twill to using the Galaxy API:



[*] For background, see my blog post:
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

To search Galaxy mailing lists use the unified search at:

Reply via email to