On Mon, Apr 04, 2011 at 13:03 +0200, Nicolas Évrard wrote:
> * holger krekel [2011-04-04 09:37 +0200]:
> >Hi Nicolas,
>
> Hello,
>
> >>Currently I use a conftest.py file in the top directory in order to
> >>define funcargs for my tests. But it looks like a suboptimal solution.
> >>
> >>I think I can use plugins in order to do the following:
> >>
> >> 1. Define a funcarg `sale` in the sale module
> >> 2. Define a funcarg `sale` in the sale_cost module. This funcarg
> >> should ideally use the funcarg from `sale` and extend it with
> >> various information (if allowed to do so by the business rule).
> >> 3. Calling py.test trytond/modules/sale_cost from the project/
> >> directory should work
> >>
> >>This setup would allow me to provide funcargs for use to other
> >>developers on which they can base their own tests.
> >>
> >>Right now I noticed that the funcargs are loaded recursively. Do you
> >>think it is possible to write a plugin that would read the dependency
> >>information in the sale_cost module and use it to setup the conftests
> >>file found in those modules to be imported *before* the conftest.py
> >>from sale_cost ?
> >>
> >>If it is, do you have any pointers on how I can do this ?
> >
> >request.getfuncargvalue() can be called to decorate an existing funcarg,
> >see http://bit.ly/eiByLF
>
> Thank you for the link I missed it while going through the doc
> (although I knew that you could call getfuncargvalue to get the
> 'previous' value and play with it).
>
> >However, i guess you could just have a single conftest.py which provides
> >different
> >values for your funcargs depending on which directory they are requested
> >from.
>
> That's precisely what I don't want to do.
OK, i didn't read your first post correctly.
> Because modules are distributed through pypi and thus you never know
> which modules are installed. Moreover, I think that such a setup would
> have many difficulties to address all the possible cases (modules
> incompatibilities, bad dependency specified in the __tryton__ file,
> and so on).
>
> My idea is the following:
>
> - During test conftest collection, locate the nearest
> __tryton__.py file (by going in the direction of the root of the
> file system).
> - Once you found it, collect also conftest information from
> the modules specified in this file (the modules are usually in a
> sibling directory from the directory where you found the
> __tryton__.py file but they may also be found thanks to their
> entry point).
> - The collection should of course work recursively
>
> It is important not to load all conftest information (because one
> might have conflicting configuration for the same object) but only the
> one you depend on.
>
> Is this kind of setup doable in a plugin ?
Hum, might be tricky. To begin with, conftest.py detection/looading
is mostly done via internal APIs. Second, conftest.py definitions
are only consulted for the particularly subdirectory so that for
a/conftest.py
b/
conftest.py
test_whatever.py
for the path "b/test_whatever.py" funcargs defined in a/conftest.py file will
not be consulted.
Maybe it's best if you experiment with your own convention. An idea could be
to define a pytest_cmdline_main() hook in your top-level conftest.py file
(which you can morph to become a pypi-installable installable pytest-tryton
plugin once it works nicely). In this hook you would look for your
__tryton__.py
file, load it and look for which modules need to be loaded. In the module
dirs you could have a "conftestresource.py" module which defines funcargs as if
you would do it in a conftest.py file. You could import this module and
register
it as a plugin to py.test like this::
config.pluginmanager.register(pluginmodule_or_object, name, prepend=True) #
or False
This way your modules grow the ability to interact with testing and
you could even use "request.getfuncargvalue()" given that your
project definitions and thus the registrations of funcarg resources are
accordingly ordered. If not you might be able to use the
"@pytest.mark.tryfirst" marker on any base object which modules
want to enhance.
You might want to read the _pytest/*.py source code a bit, grepping
for the bits and pieces i posted.
> Am I completely wrong about how this problematic should be addressed ?
Depends on if i am wrong about what i am suggesting for your situation :)
best,
holger
> >>BTW, py.test is a really nice piece of software and I really enjoy
> >>using it.
> >
> >BTW, nice to hear :)
>
> It is well deserved :).
>
> --
> (°> Nicolas Évrard
> ( ) Liège
> `¯
>
_______________________________________________
py-dev mailing list
py-dev@codespeak.net
http://codespeak.net/mailman/listinfo/py-dev
