Hi Dan, > Hi all, > > I just wanted to point out that there are several different ways to compare > the history output item to a test file beyond the default “diff”, including > contains, re_match, sim_size, etc, this is set by the “compare” attribute in > the xml tag for the test output. If you really don’t care about the contents > of an output, you could, for example, use contains against an empty file.
That is indeed a nice trick! It is potentially a way to only compare the first 1000 lines, assuming that the rest is identical. Unfortunately, I'm not able to complete the MACS2 tests, because I was not able to get conditionals of conditionals working. Is that a known bug? As I understood Greg correctly, we should not invest much more time in the twill testing and are waiting for the new API based tests? Is that correct? Thanks, Bjoern > Sorry that I didn’t provide more specific examples, as I am at a conference > this week. > > > Thanks for using Galaxy, > > Dan > > > On Feb 13, 2014, at 5:06 AM, Peter Cock <p.j.a.c...@googlemail.com> wrote: > > > On Thu, Feb 13, 2014 at 7:51 AM, Björn Grüning > > <bjoern.gruen...@gmail.com> wrote: > >> Am Mittwoch, den 12.02.2014, 10:46 +0000 schrieb Peter Cock: > >>> > >>> ... > >>> > >>> 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. > > > > I try to use small files under say 10kb if possible - partly as smaller > > unit tests are often easier to diagnose when they break, but also > > as noted above to reduce overhead for version control, and the > > ToolShed upload/download time. > > > > 50mb does sound excessive, but if that's the minimum maybe it > > is still better than no test at all? > > > >> 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 thought the test framework would allow you to provide gzipped > > input since it uses the upload tool internally which would handle > > this. If that breaks I'd consider it a bug. > > > > Gzipped output files might be more difficult, since the validation > > is based on direct file comparison. > > > > 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/
