From Ronny.Pfannschmidt at gmx.de Thu Oct 1 12:15:23 2009 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Thu, 01 Oct 2009 12:15:23 +0200 Subject: [py-dev] proposal: interaction of execnet nodes and basic node types for execnet based test execution Message-ID: <1254392123.23863.32.camel@localhost> hi, after reading holger's blog post on http://tetamap.wordpress.com/2009/09/26/elastic-python-deployment-networks/ i tought about what kinds of node are necessary/helpfull to deal with test-networks, and how they would interact, as well as some additional cappabilities i'd like to se here my basic outline: reporter they get all the test results in order to store and/or display them collector they run the test collection collecting either all tests or a given subset runner they run every single test case they are given starter they start the actual collect runs on a given node given those node types, one can imply the different execution modes standalone reporter+starter->collector->runner looponfail * like standalone, but collect and run in a different process each run * pass failures as the "given subset" (unless something like SIGHUP/a command tells otherwise) N cpus move runners to N subprocesses instead of being in the same process as the collector multiple platforms/environments at once starters on n environments within the same testnet all that would imply that looponfail sits on a starter, using reporter and collector in order to re-run the failures when file-changes are reported what i would like to do on top of that, is hook something like an ide into the testnet that will start continious testing for n opened projects in a testnet, reporting file changes to the testnet and collecting test results for the developer Regards Ronny From holger at merlinux.eu Thu Oct 1 18:51:15 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 1 Oct 2009 18:51:15 +0200 Subject: [py-dev] execnet now standalone / new web page mailing lists ... Message-ID: <20091001165114.GG15455@trillke.net> Hi all, so i've split out execnet into its own standalone independent package and its own web site using Sphinx, see here: http://codespeak.net/execnet Migrating from existing "py.execnet.*" usage should be as easy as replacing "py.execnet." with "execnet." and importing 'execnet' instead of 'py'. I also uploaded a 1.0.0alpha release to PyPI which you should be able to use for installation. This supports Python2.4-3.1. It should not require setuptools, btw. Also for everyone interested in current and future execnet please subscribe to the new mailing lists: http://codespeak.net/mailman/execnet-dev http://codespeak.net/mailman/execnet-commit Next i plan to deprecate "py.execnet.*" on the py-trunk and point to this new API-compatible package. And then head for a pylib/py.test release and a final execnet one. happy about feedback, as always. cheers, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From issues-noreply at bitbucket.org Sun Oct 4 16:31:06 2009 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Sun, 04 Oct 2009 14:31:06 -0000 Subject: [py-dev] New issue 52 in py-trunk: lack of mock objects Message-ID: New issue 52: lack of mock objects http://bitbucket.org/hpk42/py-trunk/issue/52/lack-of-mock-objects RonnyPfannschmidt on Sun, 4 Oct 2009 16:31:06 +0200: Description: i see some need to have mock objects most recent case for me would be emulating execnet channels for disconnected tests of my anyvc remote protocol handlers Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From fijall at gmail.com Tue Oct 6 10:04:10 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Tue, 6 Oct 2009 02:04:10 -0600 Subject: [py-dev] execnet now standalone / new web page mailing lists ... In-Reply-To: <20091001165114.GG15455@trillke.net> References: <20091001165114.GG15455@trillke.net> Message-ID: <693bc9ab0910060104j4365619cje27102163030b885@mail.gmail.com> > > ? ?http://codespeak.net/mailman/execnet-dev > ? ?http://codespeak.net/mailman/execnet-commit > Hey. As of now this URLs return 404 for me. Correct URLs are: http://codespeak.net/mailman/listinfo/execnet-dev http://codespeak.net/mailman/listinfo/execnet-commit Cheers, fijal From holger at merlinux.eu Tue Oct 6 10:45:11 2009 From: holger at merlinux.eu (holger krekel) Date: Tue, 6 Oct 2009 10:45:11 +0200 Subject: [py-dev] execnet now standalone / new web page mailing lists ... In-Reply-To: <693bc9ab0910060104j4365619cje27102163030b885@mail.gmail.com> References: <20091001165114.GG15455@trillke.net> <693bc9ab0910060104j4365619cje27102163030b885@mail.gmail.com> Message-ID: <20091006084511.GT15455@trillke.net> On Tue, Oct 06, 2009 at 02:04 -0600, Maciej Fijalkowski wrote: > > > > ? ?http://codespeak.net/mailman/execnet-dev > > ? ?http://codespeak.net/mailman/execnet-commit > > > > Hey. As of now this URLs return 404 for me. Correct URLs are: > > http://codespeak.net/mailman/listinfo/execnet-dev > http://codespeak.net/mailman/listinfo/execnet-commit upsie. thanks for the correction! holger From fede.naum at gmail.com Wed Oct 7 08:21:32 2009 From: fede.naum at gmail.com (Fede Naum) Date: Wed, 7 Oct 2009 17:21:32 +1100 Subject: [py-dev] py.test from inside the python console Message-ID: <357ef9ea0910062321q537c18b8mb4044999e0d1e22d@mail.gmail.com> Hello, I did a search by subject in the py-dev Archives and could not found any thread about that. I guess it is because the documentation clearly say "py.test is a *command line tool* to collect and run automated tests". I'm using as it is for some integration test but now I want to use it to run them from inside a python shell Is there a way to run the autodiscovery + run the test + get the report from inside a python console? Why do I need that? I need it because I have to do it from inside a special console (the python console provided with Maya - http://usa.autodesk.com/adsk/servlet/pc/index?siteID=123112&id=13577897) so I do not have any command line environmet to run py.test Thanks in advance Fede -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Thu Oct 8 13:47:04 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 8 Oct 2009 13:47:04 +0200 Subject: [py-dev] py.test from inside the python console In-Reply-To: <357ef9ea0910062321q537c18b8mb4044999e0d1e22d@mail.gmail.com> References: <357ef9ea0910062321q537c18b8mb4044999e0d1e22d@mail.gmail.com> Message-ID: <20091008114704.GZ15455@trillke.net> Hi Fede, On Wed, Oct 07, 2009 at 17:21 +1100, Fede Naum wrote: > Hello, I did a search by subject in the py-dev Archives and could not found > any thread about that. > I guess it is because the documentation clearly say "py.test is a *command > line tool* to collect and run automated tests". somewhat true :) > I'm using as it is for some integration test but now I want to use it to run > them from inside a python shell > Is there a way to run the autodiscovery + run the test + get the report from > inside a python console? I've attached a small "runtesthelper.py" script whose "pytest" function you could import into your environment, best through PYTHONSTARTUP. It's a bit of a hack because of "py.test.config" has some global state (using that config object is btw deprecated). > Why do I need that? > I need it because I have to do it from inside a special console (the python > console provided with Maya - > http://usa.autodesk.com/adsk/servlet/pc/index?siteID=123112&id=13577897) so > I do not have any command line environmet to run py.test makes sense. Let us now if the above works well enough and/or what you'd like to see. I'd like to see usage-from-the shell get fully supported by default. best, holger From holger at merlinux.eu Thu Oct 8 13:48:17 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 8 Oct 2009 13:48:17 +0200 Subject: [py-dev] py.test from inside the python console In-Reply-To: <20091008114704.GZ15455@trillke.net> References: <357ef9ea0910062321q537c18b8mb4044999e0d1e22d@mail.gmail.com> <20091008114704.GZ15455@trillke.net> Message-ID: <20091008114817.GE31662@trillke.net> and here is the file actually attached. holger On Thu, Oct 08, 2009 at 13:47 +0200, holger krekel wrote: > Hi Fede, > > On Wed, Oct 07, 2009 at 17:21 +1100, Fede Naum wrote: > > Hello, I did a search by subject in the py-dev Archives and could not found > > any thread about that. > > I guess it is because the documentation clearly say "py.test is a *command > > line tool* to collect and run automated tests". > > somewhat true :) > > > I'm using as it is for some integration test but now I want to use it to run > > them from inside a python shell > > Is there a way to run the autodiscovery + run the test + get the report from > > inside a python console? > > I've attached a small "runtesthelper.py" script whose "pytest" function > you could import into your environment, best through PYTHONSTARTUP. > It's a bit of a hack because of "py.test.config" has some global state > (using that config object is btw deprecated). > > > Why do I need that? > > I need it because I have to do it from inside a special console (the python > > console provided with Maya - > > http://usa.autodesk.com/adsk/servlet/pc/index?siteID=123112&id=13577897) so > > I do not have any command line environmet to run py.test > > makes sense. Let us now if the above works well enough and/or > what you'd like to see. I'd like to see usage-from-the shell > get fully supported by default. > > best, > holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu -------------- next part -------------- A non-text attachment was scrubbed... Name: runtesthelper.py Type: text/x-python Size: 409 bytes Desc: not available URL: From gnofi at wgen.net Thu Oct 8 18:39:12 2009 From: gnofi at wgen.net (Gregory Nofi) Date: Thu, 8 Oct 2009 12:39:12 -0400 Subject: [py-dev] py.test: funcargs not working with unittest.Testcase subclasses Message-ID: <68B1D18878686F44A3ADC062A4B730E504365128@wgexch05.wgenhq.net> Hello all, I am trying to use the funcargs feature with my unittest.Testcase subclasses but it appears that py.test fails to pass the additional arguments to the unittest test method. I haven't found any discussion of this anywhere, so I'm making my first post here. Here is a simple example-- # ./conftest.py def pytest_funcarg__val1(request): return True def pytest_funcarg__val2(request): return False # ./test_myunittest.py class Test(unittest.TestCase): def test_Name(self, val1, val2): assert (val1 and val2) The result- ================================================= test session starts ================================================= [...snip...] self = def runtest(self): target = self.obj args = self._args > target(*args) E TypeError: test_Name() takes exactly 3 arguments (1 given) C:\Python26\lib\site-packages\py-1.0.2-py2.6.egg\py\test\plugin\pytest_u nittest.py:65: TypeError ============================================== 1 failed in 0.08 seconds =============================================== As you can see, py.test isn't passing the 2 funcargs from conftest.py. However, if you simply remove "unittest.TestCase" from test_myunittest.py, the py.test fails as intended- self = < test_myunittest.py.Test instance at 0x00E98AF8>, val1 = True, val2 = False def test_Name(self, val1, val2): > assert (val1 and val2) E assert (True and False) tests\math\ test_myunittest.py:18: AssertionError ============================================== 1 failed in 0.08 seconds =============================================== Is there any way to incorporate the funcargs feature into the unittest compatibility? Thanks, and keep up the great tool! Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From issues-noreply at bitbucket.org Fri Oct 9 01:33:51 2009 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Thu, 08 Oct 2009 23:33:51 -0000 Subject: [py-dev] New issue 53 in py-trunk: Error during collection Message-ID: <41cee7779cc1a6dc59f0422e1b587c0d@bitbucket.org> New issue 53: Error during collection http://bitbucket.org/hpk42/py-trunk/issue/53/error-during-collection Anonymous on Fri, 9 Oct 2009 01:33:51 +0200: Description: The following test module causes an error during collection: {{{ #!python import unittest class _E(object): def __getattr__(self, tag): pass E = _E() }}} the error: {{{ #!python (default)l-rjones:foo richard$ py.test ================================================================= test session starts ================================================================== python: platform darwin -- Python 2.6.1 test object 1: /private/tmp/foo test_foo.py E ======================================================================== ERRORS ======================================================================== _________________________________________________ ERROR during collection /private/tmp/foo/test_foo.py _________________________________________________ collector = def pytest_make_collect_report(collector): result = excinfo = None try: > result = collector._memocollect() /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/test/plugin/pytest_runner.py:32: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = def _memocollect(self): """ internal helper method to cache results of calling collect(). """ > return self._memoizedcall('_collected', self.collect) /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/test/collect.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = , attrname = '_collected', function = > def _memoizedcall(self, attrname, function): exattrname = "_ex_" + attrname failure = getattr(self, exattrname, None) if failure is not None: raise failure[0], failure[1], failure[2] if hasattr(self, attrname): return getattr(self, attrname) try: > res = function() /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/test/collect.py:99: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = def collect(self): l = self._deprecated_collect() if l is not None: return l > name2items = self._buildname2items() /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/test/pycollect.py:94: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = def _buildname2items(self): # NB. we avoid random getattrs and peek in the __dict__ instead d = {} dicts = [getattr(self.obj, '__dict__', {})] for basecls in py.std.inspect.getmro(self.obj.__class__): dicts.append(basecls.__dict__) seen = {} for dic in dicts: for name, obj in dic.items(): if name in seen: continue seen[name] = True > res = self.makeitem(name, obj) /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/test/pycollect.py:111: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = , name = 'E', obj = def makeitem(self, name, obj): res = self.config.hook.pytest_pycollect_makeitem( > collector=self, name=name, obj=obj) /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/test/pycollect.py:123: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = def __call__(self, **kwargs): methods = self.hookrelay._getmethods(self.name, self.extralookup) mc = MultiCall(methods, kwargs, firstresult=self.firstresult) > return self.hookrelay._performcall(self.name, mc) /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/_com.py:120: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = , name = 'pytest_pycollect_makeitem' multicall = , '__multicall__': , 'obj': , 'name': 'E'}> def _performcall(self, name, multicall): > return multicall.execute() /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/_com.py:105: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = , '__multicall__': , 'obj': , 'name': 'E'}> def execute(self): while self.methods: method = self.methods.pop() kwargs = self.getkwargs(method) > res = method(**kwargs) /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/_com.py:25: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ collector = , name = 'E', obj = def pytest_pycollect_makeitem(collector, name, obj): if 'unittest' not in sys.modules: return # nobody could have possibly derived a subclass > if py.std.inspect.isclass(obj) and issubclass(obj, py.std.unittest.TestCase): E TypeError: issubclass() arg 1 must be a class /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/py/test/plugin/pytest_unittest.py:22: TypeError =============================================================== 1 error in 0.11 seconds ================================================================ }}} with py.test version 1.0.2 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From holger at merlinux.eu Thu Oct 8 13:47:04 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 8 Oct 2009 13:47:04 +0200 Subject: [py-dev] py.test from inside the python console In-Reply-To: <357ef9ea0910062321q537c18b8mb4044999e0d1e22d@mail.gmail.com> References: <357ef9ea0910062321q537c18b8mb4044999e0d1e22d@mail.gmail.com> Message-ID: <20091008114704.GZ15455@trillke.net> Hi Fede, On Wed, Oct 07, 2009 at 17:21 +1100, Fede Naum wrote: > Hello, I did a search by subject in the py-dev Archives and could not found > any thread about that. > I guess it is because the documentation clearly say "py.test is a *command > line tool* to collect and run automated tests". somewhat true :) > I'm using as it is for some integration test but now I want to use it to run > them from inside a python shell > Is there a way to run the autodiscovery + run the test + get the report from > inside a python console? I've attached a small "runtesthelper.py" script whose "pytest" function you could import into your environment, best through PYTHONSTARTUP. It's a bit of a hack because of "py.test.config" has some global state (using that config object is btw deprecated). > Why do I need that? > I need it because I have to do it from inside a special console (the python > console provided with Maya - > http://usa.autodesk.com/adsk/servlet/pc/index?siteID=123112&id=13577897) so > I do not have any command line environmet to run py.test makes sense. Let us now if the above works well enough and/or what you'd like to see. I'd like to see usage-from-the shell get fully supported by default. best, holger From issues-noreply at bitbucket.org Sun Oct 11 21:13:57 2009 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Sun, 11 Oct 2009 19:13:57 -0000 Subject: [py-dev] New issue 54 in py-trunk: py.process.cmdexec() hangs if stderr is full Message-ID: <5113bf3e637aa55d2ae2b0e5a069320a@bitbucket.org> New issue 54: py.process.cmdexec() hangs if stderr is full http://bitbucket.org/hpk42/py-trunk/issue/54/pyprocesscmdexec-hangs-if-stderr-is-full Victor Stinner / haypo on Sun, 11 Oct 2009 21:13:57 +0200: Description: I'm trying a debug version of PyPy which writes a lot of lines to stderr. After few seconds, PyPy hangs. strace shows that there are two processes: * parent : reading on a pipe (a) * child : writing to a pipe (b) and... pipe (a) and pipe (b) are different. The child is blocked because the pipe (b) is full, and the parent is blocking because there is no data on pipe (a). The problem is in py.process.cmdexec(): def popen3_exec_cmd(cmd): stdin, stdout, stderr = os.popen3(cmd) out = stdout.read() err = stderr.read() stdout.close() stderr.close() stderr is full but the parent is still waiting for the end of stdout (process exit). I think that stdout and stderr should be read at the same time, maybe using non blocking file descriptors and/or select. Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From fede.naum at gmail.com Mon Oct 12 07:26:55 2009 From: fede.naum at gmail.com (Fede Naum) Date: Mon, 12 Oct 2009 16:26:55 +1100 Subject: [py-dev] py.test from inside the python console In-Reply-To: <20091008114817.GE31662@trillke.net> References: <357ef9ea0910062321q537c18b8mb4044999e0d1e22d@mail.gmail.com> <20091008114704.GZ15455@trillke.net> <20091008114817.GE31662@trillke.net> Message-ID: <357ef9ea0910112226s23716efbrd650b9c431cfde42@mail.gmail.com> Hi Holger, and all, Thank you so much for the quick response, and sorry I could not come back with the results earlier. The "runtesthelper.py" works fine to run tests in a console and inside Maya without using any plugin. But I need to use the *keyword* plugin because I have to select some test that runs inside maya, and deselect other that run in another application.... I was registering it with the following code. (likely not to be the best way, and as you said it's kind of a hack using py.test.config,) import os, py os.environ['PYTEST_PLUGINS'] = 'keyword' py.test.config.pluginmanager.consider_env() py.test.config.pluginmanager.do_configure(py.test.config) but now when I used the "runtesthelper.py" I got an error, so I could not manage yet to read the keyword plugin and then execute my tests. You were saying that py.test.config is kind of deprecated.?..so, what should I use instead? Or what will be the correct way to register a plugin from inside a console and then run the test using your "runtesthelper.py" Thanks a lot Fede On Thu, Oct 8, 2009 at 10:48 PM, holger krekel wrote: > > and here is the file actually attached. > > holger > > On Thu, Oct 08, 2009 at 13:47 +0200, holger krekel wrote: > > > Hi Fede, > > > > On Wed, Oct 07, 2009 at 17:21 +1100, Fede Naum wrote: > > > Hello, I did a search by subject in the py-dev Archives and could not > found > > > any thread about that. > > > I guess it is because the documentation clearly say "py.test is a > *command > > > line tool* to collect and run automated tests". > > > > somewhat true :) > > > > > I'm using as it is for some integration test but now I want to use it > to run > > > them from inside a python shell > > > Is there a way to run the autodiscovery + run the test + get the report > from > > > inside a python console? > > > > I've attached a small "runtesthelper.py" script whose "pytest" function > > you could import into your environment, best through PYTHONSTARTUP. > > It's a bit of a hack because of "py.test.config" has some global state > > (using that config object is btw deprecated). > > > > > Why do I need that? > > > I need it because I have to do it from inside a special console (the > python > > > console provided with Maya - > > > > http://usa.autodesk.com/adsk/servlet/pc/index?siteID=123112&id=13577897) > so > > > I do not have any command line environmet to run py.test > > > > makes sense. Let us now if the above works well enough and/or > > what you'd like to see. I'd like to see usage-from-the shell > > get fully supported by default. > > > > best, > > holger > > -- > Metaprogramming, Python, Testing: http://tetamap.wordpress.com > Python, PyPy, pytest contracting: http://merlinux.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Mon Oct 12 10:50:15 2009 From: holger at merlinux.eu (holger krekel) Date: Mon, 12 Oct 2009 10:50:15 +0200 Subject: [py-dev] py.test from inside the python console In-Reply-To: <357ef9ea0910112226s23716efbrd650b9c431cfde42@mail.gmail.com> References: <357ef9ea0910062321q537c18b8mb4044999e0d1e22d@mail.gmail.com> <20091008114704.GZ15455@trillke.net> <20091008114817.GE31662@trillke.net> <357ef9ea0910112226s23716efbrd650b9c431cfde42@mail.gmail.com> Message-ID: <20091012085015.GM29141@trillke.net> Hi Fede, On Mon, Oct 12, 2009 at 16:26 +1100, Fede Naum wrote: > Hi Holger, and all, Thank you so much for the quick response, and sorry I > could not come back with the results earlier. > > The "runtesthelper.py" works fine to run tests in a console and inside Maya > without using any plugin. > But I need to use the *keyword* plugin because I have to select some test > that runs inside maya, and deselect other that run in another > application.... i think the keyword plugin is enabled by default. When i run runtesthelper.pytest(['--traceconfig', ...]) the keyword plugin should be in the "active plugins" section. > I was registering it with the following code. (likely not to be the best > way, and as you said it's kind of a hack using py.test.config,) > > import os, py > os.environ['PYTEST_PLUGINS'] = 'keyword' > py.test.config.pluginmanager.consider_env() > py.test.config.pluginmanager.do_configure(py.test.config) > > but now when I used the "runtesthelper.py" I got an error, so I could not > manage yet to read the keyword plugin and then execute my tests. If you need to add plugins setting os.environ should be enough. the startup of py.test (even through the runtesthelper script) takes care to load plugins. but again, i think there is no need to load the 'keyword' plugin in particular. > You were saying that py.test.config is kind of deprecated.?..so, what should > I use instead? Or what will be the correct way to register a plugin from > inside a console and then run the test using your "runtesthelper.py" plugin methods can get access to the config object. > Thanks a lot > Fede welcome. holger From fede.naum at gmail.com Tue Oct 13 10:20:36 2009 From: fede.naum at gmail.com (Fede Naum) Date: Tue, 13 Oct 2009 19:20:36 +1100 Subject: [py-dev] py.test from inside the python console In-Reply-To: <20091012085015.GM29141@trillke.net> References: <357ef9ea0910062321q537c18b8mb4044999e0d1e22d@mail.gmail.com> <20091008114704.GZ15455@trillke.net> <20091008114817.GE31662@trillke.net> <357ef9ea0910112226s23716efbrd650b9c431cfde42@mail.gmail.com> <20091012085015.GM29141@trillke.net> Message-ID: <357ef9ea0910130120v4bd89e85p31ae647a8d4a7b5c@mail.gmail.com> Hi Holger, you are absolutely right!!! I was just messing it up with my code. So briefly, it works fine in a console and inside the Maya console using the plugins, so I can now select and deselect the tests... Thanks you so much for you help, and congratulation for the tool, it's being very useful here best regards Fede On 12 October 2009 19:50, holger krekel wrote: > Hi Fede, > > On Mon, Oct 12, 2009 at 16:26 +1100, Fede Naum wrote: > > Hi Holger, and all, Thank you so much for the quick response, and sorry I > > could not come back with the results earlier. > > > > The "runtesthelper.py" works fine to run tests in a console and inside > Maya > > without using any plugin. > > But I need to use the *keyword* plugin because I have to select some test > > that runs inside maya, and deselect other that run in another > > application.... > > i think the keyword plugin is enabled by default. When i run > > runtesthelper.pytest(['--traceconfig', ...]) > > the keyword plugin should be in the "active plugins" section. > > > I was registering it with the following code. (likely not to be the best > > way, and as you said it's kind of a hack using py.test.config,) > > > > import os, py > > os.environ['PYTEST_PLUGINS'] = 'keyword' > > py.test.config.pluginmanager.consider_env() > > py.test.config.pluginmanager.do_configure(py.test.config) > > > > but now when I used the "runtesthelper.py" I got an error, so I could not > > manage yet to read the keyword plugin and then execute my tests. > > If you need to add plugins setting os.environ should be > enough. the startup of py.test (even through the > runtesthelper script) takes care to load plugins. > but again, i think there is no need to load the 'keyword' > plugin in particular. > > > You were saying that py.test.config is kind of deprecated.?..so, what > should > > I use instead? Or what will be the correct way to register a plugin from > > inside a console and then run the test using your "runtesthelper.py" > > plugin methods can get access to the config object. > > > Thanks a lot > > Fede > > welcome. > holger > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 5kycsae02 at sneakemail.com Thu Oct 15 05:56:59 2009 From: 5kycsae02 at sneakemail.com (Simon) Date: 15 Oct 2009 03:56:59 -0000 Subject: [py-dev] Log to a file Message-ID: <31126-32790@sneakemail.com> Hi! I would like to capture the verbose output of test runs to a file so that the debug is captured to a file regardless of whether the test failed or when the test is not running to completion. Is there an easy way of doing this via a command line option, or should I be perhaps modifying the resultlog plugin or something similar? Thanks, Simon From holger at merlinux.eu Thu Oct 15 09:33:18 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 15 Oct 2009 09:33:18 +0200 Subject: [py-dev] Log to a file In-Reply-To: <31126-32790@sneakemail.com> References: <31126-32790@sneakemail.com> Message-ID: <20091015073318.GJ29141@trillke.net> Hi Simon, On Thu, Oct 15, 2009 at 03:56 -0000, Simon wrote: > I would like to capture the verbose output of test runs to a file so that the debug is captured to a file regardless of whether the test failed or when the test is not running to completion. > > Is there an easy way of doing this via a command line option, or should I be perhaps modifying the resultlog plugin or something similar? if you are using unix, you could do: "py.test ... | tee -a log" on windows there might be something similar. Otherwise maybe indeed the resultlog plugin could grow some feature. In fact i'd like to have result logging happen to a directory and then be able to query it without running tests. best, holger From fijall at gmail.com Thu Oct 15 19:31:34 2009 From: fijall at gmail.com (Maciej Fijalkowski) Date: Thu, 15 Oct 2009 11:31:34 -0600 Subject: [py-dev] Log to a file In-Reply-To: <31126-32790@sneakemail.com> References: <31126-32790@sneakemail.com> Message-ID: <693bc9ab0910151031g5e327795m26aff82d7f028eda@mail.gmail.com> On Wed, Oct 14, 2009 at 9:56 PM, Simon <5kycsae02 at sneakemail.com> wrote: > Hi! > > I would like to capture the verbose output of test runs to a file so that the debug is captured to a file regardless of whether the test failed or when the test is not running to completion. > > Is there an easy way of doing this via a command line option, or should I be perhaps modifying the resultlog plugin or something similar? > > Thanks, > > Simon You know about py.test -s right? Cheers, fijal From holger at merlinux.eu Thu Oct 15 21:05:13 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 15 Oct 2009 21:05:13 +0200 Subject: [py-dev] generalized skipping / xfail Message-ID: <20091015190513.GX29141@trillke.net> Hi all, i've just written docs and ported bits of py.test's own test suite to the new "generalized skipping" feature. With it one can mark test functions, classes or modules for conditional skipping ... see here for more details and examples: http://codespeak.net/py/trunk/test/plugin/skipping.html feedback very welcome. best, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From issues-noreply at bitbucket.org Thu Oct 15 22:12:17 2009 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Thu, 15 Oct 2009 20:12:17 -0000 Subject: [py-dev] New issue 55 in py-trunk: Distributed Load Testing Issues Message-ID: <900310c993a972ecf07ba963f5991962@bitbucket.org> New issue 55: Distributed Load Testing Issues http://bitbucket.org/hpk42/py-trunk/issue/55/distributed-load-testing-issues dsaputo on Thu, 15 Oct 2009 22:12:17 +0200: Description: Using the py.test -n option, the txnodes seem to be ready to receive tests. The only way I've seen tests distributed to the nodes is if the tests are all in separate files, e.g. test_spam1.py, test_spam2.py, etc. Even then, it distributes unevenly with some nodes never getting any tests. If there is only one file with multiple tests, e.g. test_spam.py contains test_eggs1(), test_eggs2(), etc., it appears that all tests go to one node. If there are generated tests (using pytest_generate_tests(metafunc)), all these tests also go to one node. Is this the way it works, is this a bug, or am I doing something wrong? Python version 2.6.3 py.test version 1.0.2 Tested on Mac OS X 10.6.1 Windows XP SP2 Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From 5kycsae02 at sneakemail.com Fri Oct 16 01:15:30 2009 From: 5kycsae02 at sneakemail.com (Simon) Date: 15 Oct 2009 23:15:30 -0000 Subject: [py-dev] Log to a file Message-ID: <32401-27404@sneakemail.com> On 16/10/2009, at 04:31 , Maciej Fijalkowski fijall-at-gmail.com |py- dev + execnet-dev| wrote: > On Wed, Oct 14, 2009 at 9:56 PM, Simon <5kycsae02 at sneakemail.com> > wrote: >> Hi! >> >> I would like to capture the verbose output of test runs to a file >> so that the debug is captured to a file regardless of whether the >> test failed or when the test is not running to completion. >> >> Is there an easy way of doing this via a command line option, or >> should I be perhaps modifying the resultlog plugin or something >> similar? >> >> Thanks, >> >> Simon > > You know about py.test -s right? > > Cheers, > fijal Sorry, I wasn't particularly clear. We generally run our tests with the -v option which is fine, which produces a level of output suitable for our general day to day use. However we would also like to log the complete (-s) output to a file in the background. So that if at some point in the future we need to go through the detailed output, it is available. We'd also like this to happen in such a way that if the tests were to hang or hard crash halfway through, we still have the debug log. Any ideas? Simon From holger at merlinux.eu Fri Oct 16 12:23:38 2009 From: holger at merlinux.eu (holger krekel) Date: Fri, 16 Oct 2009 12:23:38 +0200 Subject: [py-dev] Log to a file In-Reply-To: <32401-27404@sneakemail.com> References: <32401-27404@sneakemail.com> Message-ID: <20091016102338.GZ29141@trillke.net> On Thu, Oct 15, 2009 at 23:15 -0000, Simon wrote: > On 16/10/2009, at 04:31 , Maciej Fijalkowski fijall-at-gmail.com |py- > dev + execnet-dev| wrote: > > > On Wed, Oct 14, 2009 at 9:56 PM, Simon <5kycsae02 at sneakemail.com> > > wrote: > >> Hi! > >> > >> I would like to capture the verbose output of test runs to a file > >> so that the debug is captured to a file regardless of whether the > >> test failed or when the test is not running to completion. > >> > >> Is there an easy way of doing this via a command line option, or > >> should I be perhaps modifying the resultlog plugin or something > >> similar? > >> > >> Thanks, > >> > >> Simon > > > > You know about py.test -s right? > > > > Cheers, > > fijal > > Sorry, I wasn't particularly clear. > > We generally run our tests with the -v option which is fine, which > produces a level of output suitable for our general day to day use. > > However we would also like to log the complete (-s) output to a file > in the background. So that if at some point in the future we need to > go through the detailed output, it is available. > > We'd also like this to happen in such a way that if the tests were to > hang or hard crash halfway through, we still have the debug log. > > Any ideas? I am not completely sure how to best implement it. Maybe extend the "--capture" option to specify a filename. A naive implementation would only produce the test output though, not meta-information like test name or traceback. Maybe a bit tricky to get this working for dist-testing like "-n 3" but that's probably true for any impl idea for this feature. what do you think? Capturing is done via code in the _py/test/plugin/pytest_capture.py and in _py/io/capture.py (py-trunk references) - not completely trivial code because it works hard to play nicely with tests/apps using the std logging module which assumes ownership of sys.stdout/stderr stream. Do you feel like giving it a try? I plan for a 1.1 beta1 soon so it could be available soon. best, holger From Ronny.Pfannschmidt at gmx.de Fri Oct 16 18:44:49 2009 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Fri, 16 Oct 2009 18:44:49 +0200 Subject: [py-dev] generalized skipping / xfail In-Reply-To: <20091015190513.GX29141@trillke.net> References: <20091015190513.GX29141@trillke.net> Message-ID: <1255711489.882.1.camel@localhost> On Thu, 2009-10-15 at 21:05 +0200, holger krekel wrote: > Hi all, > > i've just written docs and ported bits of py.test's own test > suite to the new "generalized skipping" feature. With it > one can mark test functions, classes or modules for > conditional skipping ... see here for more details > and examples: > > http://codespeak.net/py/trunk/test/plugin/skipping.html > > feedback very welcome. a few extended examples using funcarg values and/or generate_tests would be very appreciated Regards, Ronny From issues-noreply at bitbucket.org Mon Oct 19 18:14:59 2009 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Mon, 19 Oct 2009 16:14:59 -0000 Subject: [py-dev] New issue 56 in py-trunk: Problems testing modules in namespace package Message-ID: <0624731c60b20c6a790bfbe0a58a80d2@bitbucket.org> New issue 56: Problems testing modules in namespace package http://bitbucket.org/hpk42/py-trunk/issue/56/problems-testing-modules-in-namespace cdent on Mon, 19 Oct 2009 18:14:59 +0200: Description: When using namespace_packages if I am testing a new module in a namespace that is already installed into sys.path (e.g. an egg in that namespace is already on sys.path) then the new module fails to import when running the test file against py.test. If I run the same test file with python (and have the test executed) all goes well and the correct code is imported, and the test passes as expected. While narrowing this down I created a new namespace package and tested it in place (before installing it as an egg). That first test worked fine. I then created a second module in the same namespace and tested it before installing the first module. That tested fine. I then installed the first module. Subsequent tests of the second module failed. I'm in Python 2.6.1, py 1.0.2 on OS X 10.6.1 I have attached a tarball which ought to demonstrate this situation. Inside the tarball are two directories: test.one and test.two. Both contain modules which are destined for the test1234 namespace. As they stand the single test in test dir in each should run just fine. However if 'python setup.py install' is run in the test.one directory, installing test1234.one as egg, the test in test.two will fail to 'from test1234.two import two' (assuming that things don't work). At first glance this makes me think "oh namespace_packages" are yucky, but if you run 'python test/test_two.py' things work fine... Happy to do any additional digging about as required. Thanks. A little more cookbooky on the tarball: * tar zxvf testme.tar.gz * cd testme/test.one * py.test test # expect success * cd ../test.two * py.test test # expect success * cd ../test.one * sudo python setup.py install # install egg * cd ../test.two * py.test test/test_two.py # except failure "E ImportError: No module named two" * python test/test_two.py # expect success Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From issues-noreply at bitbucket.org Tue Oct 20 17:15:59 2009 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Tue, 20 Oct 2009 15:15:59 -0000 Subject: [py-dev] New issue 57 in py-trunk: looponfail traceback on unexpected pass of a xfail test Message-ID: <834292125e6d094baf47bcd02cedd84e@bitbucket.org> New issue 57: looponfail traceback on unexpected pass of a xfail test http://bitbucket.org/hpk42/py-trunk/issue/57/looponfail-traceback-on-unexpected-pass-of-a-xfail RonnyPfannschmidt on Tue, 20 Oct 2009 17:15:59 +0200: Description: trace on http://paste.pocoo.org/show/145976/ Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From fdg001 at gmx.net Tue Oct 20 21:02:47 2009 From: fdg001 at gmx.net (Frederik Dohr) Date: Tue, 20 Oct 2009 20:02:47 +0100 Subject: [py-dev] using funcargs for setup/teardown Message-ID: <4ADE0957.7010005@gmx.net> In a brief conversation with Holger today, I confessed that for a long time I couldn't bring myself to properly read up on funcargs. While I appreciate the obvious efforts that have gone into creating the comprehensive documentation*, it did seem just a little intimidating. (Also, I generally prefer reading code to reading prose.) Anyway, I finally played around a bit with funcargs, and it actually turned out to be fairly easy to get started: http://gist.github.com/214495 While those code samples are certainly not perfect, I figured it might be useful to share this naive quickstart approach with the class. I'll need to do more reading to assess whether or how this fits into the existing documentation though. -- Fred * http://codespeak.net/py/dist/test/funcargs.html From holger at merlinux.eu Tue Oct 20 23:09:33 2009 From: holger at merlinux.eu (holger krekel) Date: Tue, 20 Oct 2009 23:09:33 +0200 Subject: [py-dev] using funcargs for setup/teardown In-Reply-To: <4ADE0957.7010005@gmx.net> References: <4ADE0957.7010005@gmx.net> Message-ID: <20091020210933.GG29141@trillke.net> Hi Frederik, On Tue, Oct 20, 2009 at 20:02 +0100, Frederik Dohr wrote: > In a brief conversation with Holger today, I confessed that for a long > time I couldn't bring myself to properly read up on funcargs. > While I appreciate the obvious efforts that have gone into creating the > comprehensive documentation*, it did seem just a little intimidating. > (Also, I generally prefer reading code to reading prose.) It contains many examples and also a reference for the API. I consider splitting the two aspects. > Anyway, I finally played around a bit with funcargs, and it actually > turned out to be fairly easy to get started: > http://gist.github.com/214495 > > While those code samples are certainly not perfect, I figured it might > be useful to share this naive quickstart approach with the class. > I'll need to do more reading to assess whether or how this fits into the > existing documentation though. nice for understand setup - but i wonder. If py.test did some basic logging that shows which user code is invoked when (e.g. test function, setup functions, funcarg factories, plugin or conftest hooks ...) it would make such help-examples smaller and more focused. With "user code" i mean code invoked from the test tool. Below is a try at explaining funcargs from a "read-source" perspective. best & thanks for the feedback, holger A minimal example for using a funcarg begins like this:: def test_logging(tmpdir): p = tmpdir.mkdir("example") The 'tmpdir' is an empty temporary directory unique per test function. Let's use another funcarg to monkey-patch an environment variable and then do a test that our application honours it:: def test_logging(tmpdir, monkeypatch): p = tmpdir.join("logfile") monkeypatch.setenv('LOGFILE', p) ... call app which does logging ... s = p.read() assert "startup..." in s Both the tmpdir and the monkeypatch values are created from their respective funcarg factory. Here is the monkeypatch funcarg factory: http://bitbucket.org/hpk42/py-trunk/src/d9645744d8a5/_py/test/plugin/pytest_monkeypatch.py From holger at merlinux.eu Thu Oct 22 21:15:31 2009 From: holger at merlinux.eu (holger krekel) Date: Thu, 22 Oct 2009 21:15:31 +0200 Subject: [py-dev] pending py.test-1.1.0b1 / advanced skipping Message-ID: <20091022191531.GU29141@trillke.net> Hi all, Next week I'd like to package a 1.1b1 release working well with CPython 2.4-3.1, pypy and Jython. My intention is for it to be major cleanup release, backward compatible but deprecating old stuff. It will also introduce a few new features and refinements, among them generalized skipping: http://codespeak.net/py/trunk/test/plugin/skipping.html If you have any feedback or comments on this, i am happy to hear them. Bitbuckets py-trunk repo has the working code - and i am also hanging around on #pylib on freenode usually. cheers, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu From issues-noreply at bitbucket.org Fri Oct 23 10:40:29 2009 From: issues-noreply at bitbucket.org (issues-noreply at bitbucket.org) Date: Fri, 23 Oct 2009 08:40:29 -0000 Subject: [py-dev] New issue 58 in py-trunk: py.test broken with use of multiprocessing.Process Message-ID: <3c4a3d8cf7050808d9f44481ecfba597@bitbucket.org> New issue 58: py.test broken with use of multiprocessing.Process http://bitbucket.org/hpk42/py-trunk/issue/58/pytest-broken-with-use-of bluebird75 on Fri, 23 Oct 2009 10:40:28 +0200: Description: The following program clearly highlights the problem: {{{ #!python import os from multiprocessing import Process def do_task1(): print 'task1: pid=%d' % (os.getpid()) class TestProcess: def test_p1( self ): print 'test_p1: pid=%d' % os.getpid() p = Process( name='p1', target=do_task1 ) p.start() p.join() }}} Philippe at pc-philippe /cygdrive/d/work/elc-dev/tmp $ py.test -s ============================= test session starts ============================= python: platform win32 -- Python 2.6.1 test object 1: d:\work\elc-dev\tmp test_process.py test_p1: pid=3920 ============================= test session starts ============================= python: platform win32 -- Python 2.6.1 test object 1: d:\work\elc-dev\tmp test_process.py test_p1: pid=3344 ============================= test session starts ============================= python: platform win32 -- Python 2.6.1 test object 1: d:\work\elc-dev\tmp test_process.py test_p1: pid=208 ============================= test session starts ============================= python: platform win32 -- Python 2.6.1 test object 1: d:\work\elc-dev\tmp test_process.py test_p1: pid=3364 ============================= test session starts ============================= python: platform win32 -- Python 2.6.1 test object 1: d:\work\elc-dev\tmp test_process.py test_p1: pid=536 ... As you can see, Process() is restarting py.test instead of starting the target function. This is on windows XP, python 2.6.1 . Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue. From fdg001 at gmx.net Sun Oct 25 15:01:45 2009 From: fdg001 at gmx.net (Frederik Dohr) Date: Sun, 25 Oct 2009 14:01:45 +0000 Subject: [py-dev] using funcargs for setup/teardown In-Reply-To: <20091020210933.GG29141@trillke.net> References: <4ADE0957.7010005@gmx.net> <20091020210933.GG29141@trillke.net> Message-ID: <4AE45A49.70207@gmx.net> > It contains many examples and also a reference for the API. > I consider splitting the two aspects. That's probably a good idea. > If py.test did some basic logging that shows which user code is > invoked when (e.g. test function, setup functions, funcarg > factories, plugin or conftest hooks ...) it would make such > help-examples smaller and more focused. > [...] > Below is a try at explaining funcargs from a "read-source" perspective. Unfortunately, I cannot relate to this - likely due to my overall ignorance when it comes to funcargs. However, I've finally figured out why I'm having such a hard time warming up to funcargs: They go way beyond the minimalist simplicity that made me switch to py.test in the first place. (I realize there's some Magic to py.test's internals, but that doesn't surface in the API.) Funcargs seem like a departure from this principle. I understand that some situations demand such complexity, so I'm not arguing against funcargs in general - but for my part, I've managed to keep it simple so far. All of this is to say that I'm happy enough with this for setup and teardown*, but I'm probably the wrong person to comment on anything beyond that. -- F. * although I'm considering writing two decorators to easily turn any function into a setup or teardown method From fdg001 at gmx.net Sun Oct 25 19:28:21 2009 From: fdg001 at gmx.net (Frederik Dohr) Date: Sun, 25 Oct 2009 18:28:21 +0000 Subject: [py-dev] using funcargs for setup/teardown In-Reply-To: <4AE45A49.70207@gmx.net> References: <4ADE0957.7010005@gmx.net> <20091020210933.GG29141@trillke.net> <4AE45A49.70207@gmx.net> Message-ID: <4AE498C5.4000304@gmx.net> > I'm considering writing two decorators to easily turn any function > into a setup or teardown method That's done now: http://gist.github.com/214495 It was a good learning experience, and as such probably not flawless. (It's certainly more obscure than I'd like... ) -- F. From holger at merlinux.eu Mon Oct 26 11:26:28 2009 From: holger at merlinux.eu (holger krekel) Date: Mon, 26 Oct 2009 11:26:28 +0100 Subject: [py-dev] using funcargs for setup/teardown In-Reply-To: <4AE459EC.805@gmx.net> References: <4ADE0957.7010005@gmx.net> <20091020210933.GG29141@trillke.net> <4AE459EC.805@gmx.net> Message-ID: <20091026102628.GB29141@trillke.net> Hi Frederik! On Sun, Oct 25, 2009 at 14:00 +0000, Frederik Dohr wrote: >> It contains many examples and also a reference for the API. I consider >> splitting the two aspects. > > That's probably a good idea. > >> If py.test did some basic logging that shows which user code is >> invoked when (e.g. test function, setup functions, funcarg >> factories, plugin or conftest hooks ...) it would make such >> help-examples smaller and more focused. >> [...] >> Below is a try at explaining funcargs from a "read-source" perspective. >> > > Unfortunately, I cannot relate to this - likely due to my overall > ignorance when it comes to funcargs. > > However, I've finally figured out why I'm having such a hard time > warming up to funcargs: They go way beyond the minimalist simplicity > that made me switch to py.test in the first place. > (I realize there's some Magic to py.test's internals, but that doesn't > surface in the API.) > > Funcargs seem like a departure from this principle. > I understand that some situations demand such complexity, so I'm not > arguing against funcargs in general - but for my part, I've managed to > keep it simple so far. I don't want to argue "simplicity" but let me state my perspective and considerations - maybe they shed some light on why i consider the funcargs approach more powerful: test functions are Python functions. Python functions need certain objects to run. Why now use degraded Python functions for tests, i.e. ones that never receives parameters? This implies having to call magic methods for setting up objects in global namespaces or 'self' attributes - which not only makes the test harder to understand and refactor IMO. It also means that setups for different aspects, e.g. mocking a database and mocking a web service intermingle in one setup area whereas funcarg factories allow to keep such setup aspects totally separate and reuseable across the whole test suite. > All of this is to say that I'm happy enough with this for setup and > teardown*, but I'm probably the wrong person to comment on anything > beyond that. i disagree also here a bit - rather appreciate your feedback :) cheers, holger From holger at merlinux.eu Mon Oct 26 12:19:46 2009 From: holger at merlinux.eu (holger krekel) Date: Mon, 26 Oct 2009 12:19:46 +0100 Subject: [py-dev] using funcargs for setup/teardown In-Reply-To: <4AE498C5.4000304@gmx.net> References: <4ADE0957.7010005@gmx.net> <20091020210933.GG29141@trillke.net> <4AE45A49.70207@gmx.net> <4AE498C5.4000304@gmx.net> Message-ID: <20091026111945.GD29141@trillke.net> On Sun, Oct 25, 2009 at 18:28 +0000, Frederik Dohr wrote: > > I'm considering writing two decorators to easily turn any function > > into a setup or teardown method > > That's done now: > http://gist.github.com/214495 > > It was a good learning experience, and as such probably not flawless. > (It's certainly more obscure than I'd like... ) not sure i see the need for funcargs with this example - why don't you use the "traditional" setup_module/teardown_module functions? (see http://codespeak.net/py/dist/test/xunit_setup.html) best, holger From 5kycsae02 at sneakemail.com Wed Oct 28 08:22:09 2009 From: 5kycsae02 at sneakemail.com (Simon) Date: 28 Oct 2009 07:22:09 -0000 Subject: [py-dev] Log to a file Message-ID: <21883-03418@sneakemail.com> On 16/10/2009, at 21:23 , holger krekel holger-at-merlinux.eu |py-dev + execnet-dev| wrote: > On Thu, Oct 15, 2009 at 23:15 -0000, Simon wrote: >> On 16/10/2009, at 04:31 , Maciej Fijalkowski fijall-at-gmail.com |py- >> dev + execnet-dev| wrote: >> >>> On Wed, Oct 14, 2009 at 9:56 PM, Simon <5kycsae02 at sneakemail.com> >>> wrote: >>>> Hi! >>>> >>>> I would like to capture the verbose output of test runs to a file >>>> so that the debug is captured to a file regardless of whether the >>>> test failed or when the test is not running to completion. >>>> >>>> Is there an easy way of doing this via a command line option, or >>>> should I be perhaps modifying the resultlog plugin or something >>>> similar? >>>> >>>> Thanks, >>>> >>>> Simon >>> >>> You know about py.test -s right? >>> >>> Cheers, >>> fijal >> >> Sorry, I wasn't particularly clear. >> >> We generally run our tests with the -v option which is fine, which >> produces a level of output suitable for our general day to day use. >> >> However we would also like to log the complete (-s) output to a file >> in the background. So that if at some point in the future we need to >> go through the detailed output, it is available. >> >> We'd also like this to happen in such a way that if the tests were to >> hang or hard crash halfway through, we still have the debug log. >> >> Any ideas? > > I am not completely sure how to best implement it. Maybe extend the > "--capture" option to specify a filename. A naive implementation > would > only produce the test output though, not meta-information like test > name > or traceback. Maybe a bit tricky to get this working for dist- > testing like > "-n 3" but that's probably true for any impl idea for this feature. > > what do you think? > > Capturing is done via code in the _py/test/plugin/pytest_capture.py > and > in _py/io/capture.py (py-trunk references) - not completely trivial > code > because it works hard to play nicely with tests/apps using the > std logging module which assumes ownership of sys.stdout/stderr > stream. > Do you feel like giving it a try? > > I plan for a 1.1 beta1 soon so it could be available soon. > > best, > holger Hi Holger, I started looking into this a bit but ran into a problem when I started to probe the py.io module. I tried running the py.io examples on the website but when I run the py.io.StdCaptureFD example, python dies on the second line: stakita at okum:~$ python Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. History restored: /auto/home/stakita/.pyhistory, Max Length: 500 >>> import py, sys >>> capture = py.io.StdCaptureFD() stakita at okum:~$ My guess is that an exception is being thrown, but the captured sys.stderr descriptor is not passing any meaningful traceback. I tried wrapping the call in try/except, but that didn't seem to help. On the positive side, the problem appears to be quite reproducible. Any ideas on what is going on here? Regards, Simon Sysinfo: stakita at okum:~$ uname -a Linux okum 2.6.28-15-generic #51-Ubuntu SMP Mon Aug 31 13:33:16 UTC 2009 i686 GNU/Linux stakita at okum:~$ python Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. History restored: /auto/home/stakita/.pyhistory, Max Length: 500 >>> import py >>> py.version '1.0.2' From phil at freehackers.org Wed Oct 28 08:09:34 2009 From: phil at freehackers.org (Philippe Fremy) Date: Wed, 28 Oct 2009 08:09:34 +0100 Subject: [py-dev] using funcargs for setup/teardown In-Reply-To: <20091026102628.GB29141@trillke.net> References: <4ADE0957.7010005@gmx.net> <20091020210933.GG29141@trillke.net> <4AE459EC.805@gmx.net> <20091026102628.GB29141@trillke.net> Message-ID: <4AE7EE2E.1020208@freehackers.org> holger krekel wrote: > Hi Frederik! > >> However, I've finally figured out why I'm having such a hard time >> warming up to funcargs: They go way beyond the minimalist simplicity >> that made me switch to py.test in the first place. >> (I realize there's some Magic to py.test's internals, but that doesn't >> surface in the API.) >> >> Funcargs seem like a departure from this principle. >> I understand that some situations demand such complexity, so I'm not >> arguing against funcargs in general - but for my part, I've managed to >> keep it simple so far. >> I second Frederic here. I chose py.test because of the overall simplicity of the framework when you use it. The setup_module/setup_class/setup_method without any special magic other than using function, class or method names starting with test is really really nice. I am kind of worried because I could no longer find them in the documentation. I eventually found them in the xUnit documentation but that's not where I expected them. I vote for a return of this documentation to the main py.test documentation, and moving funcarg related documentation to an "advanced test setup" section. funcarg seems to be a powerful tool, but really cumbersome to grok. I find the magic trick on the naming with __myargument a bit cumbersome. I would feel more comfortable with a syntax that mimic the setup/teardown used for module, class and methods. > This implies having to call magic methods for setting up objects in > global namespaces or 'self' attributes - which not only makes the test > harder to understand and refactor IMO. I do not agree here. If I have one class with 30 unit test methods, it's easier to setup/teardown the test parameters in two methods for the whole class than modifying 30 test methods to add funcargs arguments. So, while I agree that funcargs certainly has potential, I think you should not force it onto the user and should really stress the two ways of setting up per class or per method parameters. And it would be really nice to figure out a syntax for funcarg that is more in the setup/teardown fashion. I don't see much gain of using : def pytest_funcarg__mysetup(request): return MySetup(request) class TestClass: def test_function(self, mysetup): conn = mysetup.getsshconnection() # work with conn instead of : class TestClass: def setup_class( c ): c.mysetup = MySetup() def test_function(self): conn = c.mysetup.getsshconnection() # work with conn The programming style is different, the second one is traditional OO and will be familiar to anybody coming from C++, Java or other OO world. The second one is playing more on the python capabilities. I don't find it more readable. One can argue about the advantage that each test function can take a different parameter. While true, in my testing experience, I haven't seen a pattern with many different tests taking many different parameters. I usually have groups of 5 to 10 tests taking one kind of parameter. If they need to take another kind of parameter, I will put them in a different test class. So, in my opinion, using funcargs for regular cases is a matter of style. I do see a big value in funcargs for the parameterized tests. Running the same test over and over with different parameter is a really nice feature. I think you should stress it more in the documentation. cheers, Philippe From holger at merlinux.eu Wed Oct 28 09:44:00 2009 From: holger at merlinux.eu (holger krekel) Date: Wed, 28 Oct 2009 09:44:00 +0100 Subject: [py-dev] Log to a file In-Reply-To: <21883-03418@sneakemail.com> References: <21883-03418@sneakemail.com> Message-ID: <20091028084400.GG29141@trillke.net> On Wed, Oct 28, 2009 at 07:22 -0000, Simon wrote: > On 16/10/2009, at 21:23 , holger krekel holger-at-merlinux.eu |py-dev > >> We'd also like this to happen in such a way that if the tests were to > >> hang or hard crash halfway through, we still have the debug log. > >> > >> Any ideas? > > > > I am not completely sure how to best implement it. Maybe extend the > > "--capture" option to specify a filename. A naive implementation > > would > > only produce the test output though, not meta-information like test > > name > > or traceback. Maybe a bit tricky to get this working for dist- > > testing like > > "-n 3" but that's probably true for any impl idea for this feature. > > > > what do you think? > > > > Capturing is done via code in the _py/test/plugin/pytest_capture.py > > and > > in _py/io/capture.py (py-trunk references) - not completely trivial > > code > > because it works hard to play nicely with tests/apps using the > > std logging module which assumes ownership of sys.stdout/stderr > > stream. > > Do you feel like giving it a try? > > > > I plan for a 1.1 beta1 soon so it could be available soon. > > > > best, > > holger > > Hi Holger, > > I started looking into this a bit but ran into a problem when I > started to probe the py.io module. > > I tried running the py.io examples on the website > but when I run the py.io.StdCaptureFD example, python dies on the > second line: > > stakita at okum:~$ python > Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) > [GCC 4.3.3] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > History restored: /auto/home/stakita/.pyhistory, Max Length: 500 > >>> import py, sys > >>> capture = py.io.StdCaptureFD() The redirect here happens for stdout, stderr and stdin is put to /dev/zero on the file descriptor level ... > stakita at okum:~$ ... so the python interpreter immediately gets an EOL on stdin and dies. > My guess is that an exception is being thrown, but the captured > sys.stderr descriptor is not passing any meaningful traceback. you can call py.io.StdCaptureFD(err=True, in_=False, out=False) and should be able to play with writing to stderr. > I tried wrapping the call in try/except, but that didn't seem to help. > On the positive side, the problem appears to be quite reproducible. > > Any ideas on what is going on here? just anoter recommendation. Maybe it is easiest for you to implement a "--iocapturelog=filename" option and see to send output to it from the pytest_capture plugin on the py-trunk repository. You can start experimenting by copying the pytest_capture.py file somewhere into your import path and modifying it. Your local version will override the builtin one. HTH, holger From phil at freehackers.org Wed Oct 28 10:09:22 2009 From: phil at freehackers.org (Philippe Fremy) Date: Wed, 28 Oct 2009 10:09:22 +0100 Subject: [py-dev] py.test : setup / teardown at the directory level In-Reply-To: <20090428180200.GO11963@trillke.net> References: <49F6EA81.2070106@freehackers.org> <20090428115556.GJ11963@trillke.net> <49F71C0E.3000800@freehackers.org> <20090428180200.GO11963@trillke.net> Message-ID: <4AE80A42.5030009@freehackers.org> holger krekel wrote: > Hi Philippe, > > your described use case makes lots of sense to me. > > I coded an example which i hope fits it. > > It uses the new "local plugins" (i.e. plugins defined in a > conftest.py) and funcargs, if you don't know about them > yet i hope this is good to skim/read first: > http://codespeak.net/py/trunk/test/funcargs.html > > Here is the example: > > http://bitbucket.org/hpk42/py-trunk/src/tip/example/funcarg/lazysetup/ > > using py-trunk (probably also works with the 1.0.0b1, haven't checked) > in the lazysetup directory you can now do > > py.test sub1 # will wait 5 seconds because test > # functions access the setup defined in > # conftest.py > > py.test sub2 # will immediately run as the "setup" > # funcarg is not requested > > The idea for this conftest.py implementation is simple: > setup the funcarg when first needed and only tear it down > when the test process exits. > > does this make sense to you? feel free to play around > and ask questions - I'd then put the above example into > the "tutorial" example section of the funcarg doc. > > One advantage of the above approach is that you do not > need to do anything in your test modules anymore > (no boilerplate importing of setup_module etc.) > than requesting the object you want to setup. > I am reviving this old thread. Honestly, I haven't tried the funcargs based solution that you propose. The reasons are : - I would really prefer to have setup/teardown at directory level and your solution is more per-session level - I don't like the idea of modifying 100 tests just to get a setup/teardown effect - I still find funcargs a bit cumbersome as explained in my other mail. I had a quick look at the plugin architecture to see if I could implement an equivalent of setup/teardown at directory level, but I don't think it's possible. Can you consider this as a feature request ? cheers, Philippe From 5kycsae02 at sneakemail.com Thu Oct 29 07:42:17 2009 From: 5kycsae02 at sneakemail.com (Simon) Date: Thu, 29 Oct 2009 17:42:17 +1100 Subject: [py-dev] Log to a file In-Reply-To: <20091028084400.GG29141@trillke.net> References: <21883-03418@sneakemail.com> <20091028084400.GG29141@trillke.net> Message-ID: <18738-78272@sneakemail.com> On 28/10/2009, at 19:44 , holger krekel holger-at-merlinux.eu |py-dev + execnet-dev| wrote: >> Hi Holger, >> >> I started looking into this a bit but ran into a problem when I >> started to probe the py.io module. >> >> I tried running the py.io examples on the website >> but when I run the py.io.StdCaptureFD example, python dies on the >> second line: >> >> stakita at okum:~$ python >> Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) >> [GCC 4.3.3] on linux2 >> Type "help", "copyright", "credits" or "license" for more >> information. >> History restored: /auto/home/stakita/.pyhistory, Max Length: 500 >>>>> import py, sys >>>>> capture = py.io.StdCaptureFD() > > The redirect here happens for stdout, stderr and stdin is put to > /dev/zero on the file descriptor level ... > >> stakita at okum:~$ > > ... so the python interpreter immediately gets an EOL on stdin and > dies. So does this mean that the example is a bit broken then? >> My guess is that an exception is being thrown, but the captured >> sys.stderr descriptor is not passing any meaningful traceback. > > you can call py.io.StdCaptureFD(err=True, in_=False, > out=False) and should be able to play with writing to stderr. > >> I tried wrapping the call in try/except, but that didn't seem to >> help. >> On the positive side, the problem appears to be quite reproducible. >> >> Any ideas on what is going on here? > > just anoter recommendation. Maybe it is easiest for you to implement > a "--iocapturelog=filename" option and see to send output to > it from the pytest_capture plugin on the py-trunk repository. > You can start experimenting by copying the pytest_capture.py > file somewhere into your import path and modifying it. Your > local version will override the builtin one. > > HTH, > holger Thanks for the suggestion, and here is a first pass. Attached is a modified version of pytest_capture.py from the 1.0.2 release. In this file, I just push the options into the CaptureManager so that the command line args are available. This does mean that the config file options stuff is not hooked up, but at least it works from the command line at the moment. Additional plugin command line options are: --log-file When used with the two capture options ('fd' and 'sys') this will enable pushing the stdout and stderr writes to the specified file. --append-log This allows appending to the file as opposed to the default clobber behaviour. Does this fit with your model of how the plugin should be structured? Regards, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pytest_capture.py Type: text/x-python-script Size: 11688 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedronis at openend.se Thu Oct 29 17:34:55 2009 From: pedronis at openend.se (Samuele Pedroni) Date: Thu, 29 Oct 2009 17:34:55 +0100 Subject: [py-dev] is anybody seeing this kind of explosion? Message-ID: <4AE9C42F.7040006@openend.se> py lib trunk is exploding this way for me right now, I removed pyc files btw pedronis at vitaly:~/scratch/jskit-nightly$ /u/pedronis/vjskit/bin/python py-trunk/py/bin/py.test --help inserting into sys.path: /u/pedronis/scratch/jskit-nightly/py-trunk Traceback (most recent call last): File "py-trunk/py/bin/py.test", line 3, in py.cmdline.pytest() File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/test/cmdline.py", line 11, in main config = py.test.config File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line 56, in __getattr__ result = importobj(modpath, attrname) File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line 23, in importobj module = __import__(modpath, None, None, ['__doc__']) File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/test/config.py", line 2, in from _py.test.conftesthandle import Conftest File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/test/conftesthandle.py", line 2, in defaultconftestpath = py.path.local(__file__).dirpath("defaultconftest.py") File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/path/local.py", line 135, in __new__ elif isinstance(path, py.builtin._basestring): File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line 56, in __getattr__ result = importobj(modpath, attrname) File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line 24, in importobj return getattr(module, attrname) AttributeError: 'module' object has no attribute '_basestring' From holger at merlinux.eu Fri Oct 30 00:42:11 2009 From: holger at merlinux.eu (holger krekel) Date: Fri, 30 Oct 2009 00:42:11 +0100 Subject: [py-dev] is anybody seeing this kind of explosion? In-Reply-To: <4AE9C42F.7040006@openend.se> References: <4AE9C42F.7040006@openend.se> Message-ID: <20091029234211.GK29141@trillke.net> On Thu, Oct 29, 2009 at 17:34 +0100, Samuele Pedroni wrote: > py lib trunk is exploding this way for me right now, I removed pyc files btw is this maybe an empty py/builtin directory? ("bin/py.cleanup" -d should remove empty directories with a recent checkout) holger > pedronis at vitaly:~/scratch/jskit-nightly$ /u/pedronis/vjskit/bin/python > py-trunk/py/bin/py.test --help > inserting into sys.path: /u/pedronis/scratch/jskit-nightly/py-trunk > Traceback (most recent call last): > File "py-trunk/py/bin/py.test", line 3, in > py.cmdline.pytest() > File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/test/cmdline.py", > line 11, in main > config = py.test.config > File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line > 56, in __getattr__ > result = importobj(modpath, attrname) > File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line > 23, in importobj > module = __import__(modpath, None, None, ['__doc__']) > File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/test/config.py", > line 2, in > from _py.test.conftesthandle import Conftest > File > "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/test/conftesthandle.py", > line 2, in > defaultconftestpath = > py.path.local(__file__).dirpath("defaultconftest.py") > File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/path/local.py", > line 135, in __new__ > elif isinstance(path, py.builtin._basestring): > File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line > 56, in __getattr__ > result = importobj(modpath, attrname) > File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line > 24, in importobj > return getattr(module, attrname) > AttributeError: 'module' object has no attribute '_basestring' > > > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu