[py-dev] pytest tmpdir / test directories

[holger krekel]

Hi Ronny, CCing py-dev again, was lost in between,

On Wed, Jun 06, 2012 at 14:44 +0200, Ronny Pfannschmidt wrote:
> On 06/06/2012 02:35 PM, holger krekel wrote:
> >On Tue, Jun 05, 2012 at 08:18 +0200, Ronny Pfannschmidt wrote:
> >>Hi Holger,
> >>
> >>i was thinking of just naming the current tmpdir funcarg testdatadir,
> >>and implementing tmpdir in terms of testdatadir.ensure('tmpdir', dir=1)
> >
> >sure.  no immediate need to have this as a pytest core plugin, i guess.
> >
> 
> this as meant as a patch to pytests tmpdir plugin

Ah, i slowly get it.  If you get to the habit of providing a full example 
of things at the beginning i might be able to understand things quicker.

I am hesitant because it introduces another generic core funcarg which
needs explanation and examples for relatively little benefit.  I'd
rather suggest to think about extending reporting such that the paths
to interesting files for a (failing) test are presented, like in your
example the one to couchdb.dump

best,
holger


> -- Ronny
> 
> >holger
> >
> >>-- Ronny
> >>
> >>On 06/04/2012 04:49 PM, holger krekel wrote:
> >>>Hi Ronny,
> >>>
> >>>i think you could implement your scheme by writing maybe a "testdir"
> >>>funcarg (a py.path.local object) which has a .tmpdir attribute.
> >>>
> >>>The existing "testdatadir" is only for internal purposes and a
> >>>bit convoluted anyway - i don't want to promote its usage but i
> >>>also don't currently feel like refactoring it on a large scale.
> >>>
> >>>best,
> >>>holger
> >>>
> >>>On Tue, May 15, 2012 at 19:17 +0200, Ronny Pfannschmidt wrote:
> >>>>Hi Holger,
> >>>>
> >>>>currently, the tmpdir funcarg creates a directory like::
> >>>>
> >>>>   /tmp/pytest-0/test_python0
> >>>>
> >>>>i currently abuse that in a plugin to store db dump, that currently
> >>>>looks like::
> >>>>
> >>>>   $ tree /tmp/pytest-0/test_python0
> >>>>   /tmp/pytest-0/test_python0
> >>>>   |-- couchdb.dump
> >>>>   `-- proc
> >>>>
> >>>>where couchdb.dump is a database dump, thats actually related to a
> >>>>test, but shouldnt really be in its tmpdir,
> >>>>
> >>>>while proc is a directory actually created by the test
> >>>>
> >>>>i would rather have the following tree::
> >>>>
> >>>>   /tmp/pytest-0/ (test session root as before)
> >>>>    test_python0 (test data directory for that test)
> >>>>      couchdb.dump (the db dump)
> >>>>      tmpdir (this path will be in the
> >>>>        proc (the directory the test actually made)
> >>>>
> >>>>
> >>>>so testdatadir will be a funcarg *and* literally a directory that
> >>>>will be used by other functionalities as a place to put data,
> >>>>
> >>>>tmpdir would just be a directory within that
> >>>>
> >>>>if this structure is a given,
> >>>>we can also easily add per test coverage data and some extra dumps
> >>>>(like for example a logging filehandler)
> >>>>
> >>>>without disturbing expectations about having a clean tmpdir
> >>>>
> >>>>also i would like to grab screenshoots there as well
> >>>>(acceptance tests with a headless webkit)
> >>>>
> >>>>-- Ronny
> >>>>
> >>>>On 05/15/2012 06:56 PM, holger krekel wrote:
> >>>>>Hi Ronny,
> >>>>>
> >>>>>On Sun, May 13, 2012 at 10:26 +0200, Ronny Pfannschmidt wrote:
> >>>>>>Hi Holger,
> >>>>>>
> >>>>>>for one of my pytest plugins i drop out files, that dont exctly fit
> >>>>>>tmpdir, so i'd like to propose to flip it around a bit,
> >>>>>>
> >>>>>>so we get a testdatadir funcarg/directory and tmpdir is a directory below it
> >>>>>
> >>>>>confused a bit - do you literally mean funcarg/directory?
> >>>>>could you give a more concrete example?
> >>>>>
> >>>>>>from pytest plugins i'd use it to drop things like screenshots
> >>>>>>(pytest-ghost i.e. headless webkit),
> >>>>>>db dumps (pytest_couchdbkit)
> >>>>>>and later mabe for something like per test coverage reports
> >>>>>>
> >>>>>>for later it would also be nice to be able to transfer that data
> >>>>>>with a report and store it in some kind of test repository (for my
> >>>>>>thesis i'll probably prototype a couchdb one)
> >>>>>
> >>>>>I'd definitely like to see a test result repository and give test code
> >>>>>the possibility to create some payload and make this easily accessible
> >>>>>from outside a test run for visualization or other purposes.  I'd like
> >>>>>to list a few use cases for such a repository and then design the API.
> >>>>>But this is rather something post-may.
> >>>>>
> >>>>>holger
> >>>>>
> >>>>>>
> >>>>>>-- Ronny
> >>>>>>
> >>>>
> >>
>