Hello all,

Given the precedent that the test framework uses tool_conf.xml.sample
rather than tool_conf.xml, I would expect it to use example.loc.sample
rather than example.loc when running unit tests with parameters whose
values come from a loc file. This is not the case.

When writing unit tests of the Tool Shed, we can assume that as part
of the automated installation example.loc will be generated from the
supplied example.loc.sample file - and so for things like the nightly
automated testing on the Tool Shed, the files will be the same.

However, on real Galaxy installations, the administrator will likely
edit example.loc and it will not match example.loc.sample any more.
This means that for writing a unit test, I cannot make any assumptions
about the contents of example.loc, but it would be reasonable to
expect example.loc.sample setup will still match the unit tests.

Is it sensible to make the test framework load *.loc.sample rather than
*.loc for this reason?

If not, how exactly are unit tests dependent on values in a loc file
meant to be written?

This is a problem for me writing tests for Blast2GO (property files
in blast2go.loc), BLAST+ (databases in blastdb.loc etc). It hasn't
yet been a problem for Effective T3 as here my effectiveT3.loc
file still matches the sample file.


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