From hsoft at hardcoded.net  Sun Jan  2 17:25:45 2011
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Sun, 2 Jan 2011 17:25:45 +0100
Subject: [py-dev] Using funcargs (monkeypatch, tmpdir) during setup
Message-ID: <23FBE351-C149-4EE0-92CC-207810B0FA84@hardcoded.net>

Hi all, it's me again.

I'm wondering what's the common pattern of pytest users regarding the use of monkey-patching and temporary directories in setup functions. I already have my own "home-brewed" (again!) mechanism for that, but I want to "pytest-ify" the way I write tests.

So far, the only solution I can come up with is to have all tests use the funcarg(s) and pass them to the setup function when they're called. Example:

def my_setup(monkeypatch, tmpdir):
    moneypatch.setattr(module, 'something', foo)
    tmpdir.mkdir('bar')

def test1(monkeypatch, tmpdir):
    my_setup(monkeypatch, tmpdir)
    # test stuff

def test2(monkeypatch, tmpdir):
    my_setup(monkeypatch, tmpdir)
    # test stuff

This code works, but it seems repetitive to me, especially if only the setup use the monkeypatching and tmpdir, not the tests themselves. What are other pytest users doing in these situations? Is there some clever trick I'm unaware of? I'm certainly not the only person in that situation, am I?

Thanks,
Virgil Dupras

From flub at devork.be  Tue Jan  4 09:40:35 2011
From: flub at devork.be (Floris Bruynooghe)
Date: Tue, 4 Jan 2011 08:40:35 +0000
Subject: [py-dev] Using funcargs (monkeypatch, tmpdir) during setup
In-Reply-To: <23FBE351-C149-4EE0-92CC-207810B0FA84@hardcoded.net>
References: <23FBE351-C149-4EE0-92CC-207810B0FA84@hardcoded.net>
Message-ID: <AANLkTinMQfZOziPD+np=L5FP4fUfdu7B5HJmKxjZY0=m@mail.gmail.com>

Hello Virgil

On 2 January 2011 16:25, Virgil Dupras <hsoft at hardcoded.net> wrote:
> I'm wondering what's the common pattern of pytest users regarding the use of monkey-patching and temporary directories in setup functions. I already have my own "home-brewed" (again!) mechanism for that, but I want to "pytest-ify" the way I write tests.
>
> So far, the only solution I can come up with is to have all tests use the funcarg(s) and pass them to the setup function when they're called. Example:
>
> def my_setup(monkeypatch, tmpdir):
> ? ?moneypatch.setattr(module, 'something', foo)
> ? ?tmpdir.mkdir('bar')

I usually do this by creating a new funcarg for the required setup:

def pytest_funcarg__my_setup(request):
    monkey = request.getfuncargvalue(monkeypatch)
    monkey.setattr(module, 'something', foo)
    tmpdir = request.getfuncargvalue(tmpdir)
    return tmpdir.mkdir('bar')

def test1(my_setup):
    pass

This seems a fairly neat solution to me.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org


From hsoft at hardcoded.net  Tue Jan  4 10:58:51 2011
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Tue, 4 Jan 2011 10:58:51 +0100
Subject: [py-dev] Using funcargs (monkeypatch, tmpdir) during setup
In-Reply-To: <AANLkTinMQfZOziPD+np=L5FP4fUfdu7B5HJmKxjZY0=m@mail.gmail.com>
References: <23FBE351-C149-4EE0-92CC-207810B0FA84@hardcoded.net>
	<AANLkTinMQfZOziPD+np=L5FP4fUfdu7B5HJmKxjZY0=m@mail.gmail.com>
Message-ID: <ED1CC43B-44EB-4331-A265-6B2D84549450@hardcoded.net>

On 2011-01-04, at 9:40 AM, Floris Bruynooghe wrote:

> Hello Virgil
> 
> On 2 January 2011 16:25, Virgil Dupras <hsoft at hardcoded.net> wrote:
>> I'm wondering what's the common pattern of pytest users regarding the use of monkey-patching and temporary directories in setup functions. I already have my own "home-brewed" (again!) mechanism for that, but I want to "pytest-ify" the way I write tests.
>> 
>> So far, the only solution I can come up with is to have all tests use the funcarg(s) and pass them to the setup function when they're called. Example:
>> 
>> def my_setup(monkeypatch, tmpdir):
>>    moneypatch.setattr(module, 'something', foo)
>>    tmpdir.mkdir('bar')
> 
> I usually do this by creating a new funcarg for the required setup:
> 
> def pytest_funcarg__my_setup(request):
>    monkey = request.getfuncargvalue(monkeypatch)
>    monkey.setattr(module, 'something', foo)
>    tmpdir = request.getfuncargvalue(tmpdir)
>    return tmpdir.mkdir('bar')
> 
> def test1(my_setup):
>    pass
> 
> This seems a fairly neat solution to me.
> 
> Regards
> Floris
> 
> -- 
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org

I didn't know about request.getfuncargvalue(). Yup, that seems like a nice way to solve my problem, thanks!

Quick note though (for other people reading): I made a quick test and the argument to getfuncargvalue() is a string, so the correct way to call it is request.getfuncargvalue('monkeypatch').

Thanks again,
Virgil

From samuele.pedroni at gmail.com  Mon Jan 10 21:06:25 2011
From: samuele.pedroni at gmail.com (Samuele Pedroni)
Date: Mon, 10 Jan 2011 21:06:25 +0100
Subject: [py-dev] =?utf-8?q?=EF=BB=BFANN=3A_oejskit_0=2E9=2E0_JavaScript_i?=
	=?utf-8?q?n-browser_testing=2C_now_with_py=2Etest_2=2E0_support?=
Message-ID: <AANLkTimoTb9ekCwge16XoVZuQEp3-KMwPw4=P=dJr=Aj@mail.gmail.com>

Hi, I'm happy to announce a new release of OE jskit 0.9.0, just pushed
to PyPI. Main highlights:

- *py.test 2.0 is now supported!* py.test 1.x still works as well

- reusing one page (tab/window) for all tests using the same setup in
  a session is now the default, this is enforced when using py.test
  2.0 which collects all tests first

- to make the one test page more functional, jskit displays during the
  test run a list of links on the upper right corner of the pages to
  easily jump to specific outcome section for a JavaScript test files
  or python module with JavaScript tests.


About OE jskit:

jskit contains infrastructure and in particular a py.test plugin to
enable running unit tests for JavaScript code inside browsers.  It
contains also glue code to run JavaScript tests from unittest.py based
test suites.

The approach also enables to write integration tests such that the
JavaScript code is tested against server-side Python code mocked as
necessary. Any server-side framework that can already be exposed
through WSGI can play.

The plugin works with py.test 2.0 or late py.test 1.x.

More information and downloading at:

http://pypi.python.org/pypi/oejskit


jskit was initially developed by Open End AB and is released under the
MIT license.

Samuele Pedroni


From holger at merlinux.eu  Tue Jan 11 16:00:35 2011
From: holger at merlinux.eu (holger krekel)
Date: Tue, 11 Jan 2011 16:00:35 +0100
Subject: [py-dev] use of md5 checksum in
	config.py/getconftestmodules	looks fishy
In-Reply-To: <87lj3b6ndq.fsf@muni.brainbot.com>
References: <87lj3b6ndq.fsf@muni.brainbot.com>
Message-ID: <20110111150035.GG2145@trillke.net>

hi Ralf,

On Mon, Dec 27, 2010 at 20:12 +0100, Ralf Schmitt wrote:
> 
> _pytest/config.py contains the following code:
> 
> ,----
> | ...
> | conftestpath = path.join("conftest.py")
> | if conftestpath.check(file=1):
> |     key = conftestpath.computehash()
> |     # XXX logging about conftest loading
> |     if key not in self._md5cache:
> |         clist.append(self.importconftest(conftestpath))
> |         self._md5cache[key] = conftestpath
> |     else:
> |         # use some kind of logging
> |         print ("WARN: not loading %s" % conftestpath)
> `----
> 
> If I put multiple conftest.py files with the same content into different
> subdirecties py.test will only read one of them. I try to make py.test
> ignore multiple subdirectories by putting the same conftest.py file into
> those subdirectories. py.test currently only ignores one of those.

Right, this is suprising.  Motvation for above code was to
make source trees work which are recursively copied into a subdir
(which can happen with e.g. tox, copying/isntalling thingss into .tox).
But i think this does more harm than good, as shown by your usage.

I just committed a removal of the feature.  So to avoid recursion
problems one might need to throw in a "--confcutdir=." or so to prevent
py.test from looking up too much.

cheers,
holger


From cklinger at novareto.de  Wed Jan 19 14:43:22 2011
From: cklinger at novareto.de (Christian Klinger)
Date: Wed, 19 Jan 2011 14:43:22 +0100
Subject: [py-dev] py.test doctest and hooks...
Message-ID: <4D36EA7A.5020801@novareto.de>

Hello,

are there any hooks in pytest which are executed before doctests are 
executed?
I try to setup some stuff, which i want to hide in the doctest.

I already tried some "normal" pytest hooks ala:

- pytest_runtest_call(item):- pytest_runtest_setup(item): But none of 
them seems to be executed on doctest execution. Any ideas? Christian



From holger at merlinux.eu  Wed Jan 19 19:11:39 2011
From: holger at merlinux.eu (holger krekel)
Date: Wed, 19 Jan 2011 19:11:39 +0100
Subject: [py-dev] py.test doctest and hooks...
In-Reply-To: <4D36EA7A.5020801@novareto.de>
References: <4D36EA7A.5020801@novareto.de>
Message-ID: <20110119181139.GA15381@trillke.net>

Hi Christian, 

On Wed, Jan 19, 2011 at 14:43 +0100, Christian Klinger wrote:
> Hello,
> 
> are there any hooks in pytest which are executed before doctests are 
> executed?
> I try to setup some stuff, which i want to hide in the doctest.

doctest modules or doctest files ("test_*.txt")?
 
> I already tried some "normal" pytest hooks ala:
> 
> - pytest_runtest_call(item):- pytest_runtest_setup(item): But none of 
> them seems to be executed on doctest execution. Any ideas? Christian

Works for me.  Just tried a conftest.py like this:

    import pytest

    def pytest_runtest_setup(item): 
        pytest.set_trace()

and in the same dir a doc.txt like this:

    >>> 3
    4

and then run "py.test -s" which invokes the setup hook
using pytest-2.0.0 for me.

Not sure if this is sufficient for your setup purposes, though.  
Do you want to inject custom objects into the namespace
for your doctests by chance? 

If so you might want to look into

    https://bitbucket.org/hpk42/pytest/src/88c0e00cfe8b/_pytest/doctest.py

and enhance it to suit your purposes (pass "extraglobs") and then submit back
the mods including a test.   

On a more general note, it actually makes might make
sense to port the way nose is doing it, see here:

http://packages.python.org/nose/doc_tests/test_doctest_fixtures/doctest_fixtures.html

cheers,
holger