On Tue, Feb 11, 2014 at 5:09 PM, Peter Cock <p.j.a.c...@googlemail.com> wrote:
> On Tue, Feb 11, 2014 at 4:42 PM, Peter Cock <p.j.a.c...@googlemail.com> wrote:
>> On Tue, Feb 11, 2014 at 3:41 PM, Dave Bouvier <d...@bx.psu.edu> wrote:
>>> Peter,
>>> Thanks for pointing this out, I've applied your changes in
>>> 12478:15fc8675064e on the default branch.
>>>    --Dave B.
>> Thanks Dave,
>> RE: http://lists.bx.psu.edu/pipermail/galaxy-dev/2014-February/018154.html
>> https://bitbucket.org/galaxy/galaxy-central/commits/15fc8675064ea46b7e081d9643393be354f07d65
>> I'm still digging into the underlying problem, by focussing on just
>> one unit test ...
>> As a workaround, I could probably provide expected data for all
>> four output files...

Confirmed, providing a reference file for each output works:

            <param name="job_type" value="genome" />
            <param name="job_quality" value="accurate" />
            <param name="type" value="none" />
            <param name="filenames" value="ecoli.fastq" ftype="fastqsanger" />
            <output name="out_fasta" file="ecoli.mira4_de_novo.fasta"
ftype="fasta" />
            <output name="out_bam" file="ecoli.mira4_de_novo.bam" ftype="bam" />
            <output name="out_maf" file="ecoli.mira4_de_novo.mira"
ftype="mira" />
            <output name="out_log" file="ecoli.mira4_de_novo.log"
ftype="txt" lines_diff="2000" />

However, at only 5kb the FASTA file is small and fine to bundle -
but the BAM (49kb), log (123kb) and MAF (764kb) quickly add
up so I would prefer not to have to include these (under source
code control, and for the Tool Shed upload). Also, as you might
guess from the large number of allowed differences, the log
file is quite variable (lots of time stamps plus Galaxy's temp
filenames appear).

> I've been talking to John (off list), he will reply here later, but in
> the meantime pointed me at a relevant commit,
> https://bitbucket.org/galaxy/galaxy-central/commits/d05be33ad6b772c2a688d875c4cf895d6afac4e3
> Basically the current Twill tests are extremely fragile and expect the
> test output files in the same order used in the <outputs> definitions
> and also there must be sample data for ALL the output files.
> (I may have hit this bug before, I forget now).

I think it ought be possible to refactor the Twill test code to use
the same dictionary approach used in the API based testing -
and so support listing the test output in any order and only
testing some of the files.

However, I'll wait and see what you guys have to say.

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