Hi Björn, I think twill is going to be around for a while yet, but it is quickly becoming more critical to eliminate it. I haven't yet looked at Johns tests using the API, but my understanding is that they are focused on tools. We're using twill a lot in other areas besides tools, so it will require some work to eliminate it completely. Some enhancements to our twill framework will undoubtedly be necessaruy form some time. However, non-trivial enhancements should be thought about carefully. Thanks! Greg Von Kuster On Feb 13, 2014, at 5:46 PM, Björn Grüning <bjoern.gruening@gmail.com> wrote:
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.cock@googlemail.com> wrote:
On Thu, Feb 13, 2014 at 7:51 AM, Björn Grüning <bjoern.gruening@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/