[TIP] why you should distribute tests with your application / module

Jesse Noller jnoller at gmail.com
Thu Sep 18 08:03:02 PDT 2008

On Thu, Sep 18, 2008 at 10:38 AM, Kumar McMillan
<kumar.mcmillan at gmail.com> wrote:
> On Wed, Sep 17, 2008 at 9:04 PM, Pete <pfein at pobox.com> wrote:
>>>> Yeah, this is pretty much what I had in mind / suggested earlier.
>>>> Seems like this would make a decent nose plugin (--download-test-
>>>> data)... not that I'm likely to write it. ;-)
>>>> Thanks all.
>>>> --Pete
>>> I/we could hack it out exceedingly quickly - what do you see it doing,
>>> accepting in a URL and unzipping it? Do you want it to be a command
>>> line argument (i.e: url) or an artifact in the nose config file?
>> Ideal solution:
>> The plugin provides a external_data(url, unpack=True) function, which
>> returns a path on the local disk where the test data lives.  The
>> plugin adds a --download-external-data option to control whether the
>> data is retrieved or not.  If the data isn't available and that option
>> is not specified, external_data raises SkipTest.
> you could also specify a hash in the test code itself and that can be
> used for 1) verification of the dataset after download and 2) to
> control local caching so that the data is not constantly fetched if it
> did not change and exists locally.
>> The user would need to specify a directory for storing the external
>> data in, probably in their .noserc.  Using httplib2 for the d/l'ding
>> might make the file management trivial, as it supports on disk caching
>> already. Otherwise, you'd need to track what files correspond to which
>> URLs.  Not hard, but if httplib2 can do it for you, it's laziness ftw.
>> Names & functionality subject to change.  Unpacking should probably
>> support .gz, .tar.gz & .zip (all pretty straightforward w/ stdlib).
>> I originally thought of less ambitious solutions - just specifying a
>> list of URLs in the config file/command line, say.  But doing so
>> doesn't seem to add much beyond including a simple downloading script
>> in the package itself.
>> Thanks!  Lemme know how I can help.

FWIW - I think this may be a decent addition of features to my
nose-testconfig plugin, let me look at it


More information about the testing-in-python mailing list