Am Mittwoch, den 12.02.2014, 10:46 +0000 schrieb Peter Cock:
> 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:
> 
>         <test>
>             <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" />
>         </test>
> 
> 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).

Do you have any advise which filesize is feasible and at which point we
should skip the tests? I'm working currently on MACS2 wrappers and to
have reasonable tests I need up to 50mb ob test files. Providing gz
input files would be one option to get it down to 10mb, but that does
not work and it's still 10mb ...

> > 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.
> 
> Peter.
> ___________________________________________________________
> 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:
>   http://lists.bx.psu.edu/
> 
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/mailinglists/


___________________________________________________________
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:
  http://lists.bx.psu.edu/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Reply via email to