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

[Kumar McMillan]

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.
>
> --Pete
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>