On Mon, Sep 16, 2013 at 2:38 PM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
On Mon, Sep 16, 2013 at 2:30 PM, Dave Bouvier <dave@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. https://travis-ci.org/peterjc/galaxy_blast/builds/13309196 https://github.com/peterjc/galaxy_blast/commit/6095b8bcabbefa412259de3cc6bd6...
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: https://trello.com/c/MsJctFem/1135-refactor-tool-testing-framework-to-use-ap... Peter [*] For background, see my blog post: http://blastedbio.blogspot.co.uk/2013/09/using-travis-ci-for-testing-galaxy-...