From grig at agilistas.org Fri Feb 9 00:32:59 2007 From: grig at agilistas.org (Grig Gheorghiu) Date: Thu, 8 Feb 2007 15:32:59 -0800 Subject: [py-dev] py lib test failures on Ubuntu Breezy buildbot Message-ID: FYI: http://www.python.org/dev/buildbot/community/all/x86%20Ubuntu%20Breezy%20trunk/builds/328/step-py.lib/0 Grig From holger at merlinux.de Mon Feb 12 01:45:28 2007 From: holger at merlinux.de (holger krekel) Date: Mon, 12 Feb 2007 01:45:28 +0100 Subject: [py-dev] release beta / new docs/website Message-ID: <20070212004528.GA16146@solar.trillke> Hi all, so the release is actually approaching despite all kinds of things trying to prevent it (most notably myself :). On http://codespeak.net/py/dist/ you find a set of updated documentation and also links to the API documentation tool where guido has been working on a lot. The links across the various web pages may not be completely consistent yet. Here is a release announcement draft: http://codespeak.net/py/dist/release-0.9.0.html There are no downloads active yet (and still some pypy problems that may make fixing on py lib's side neccessary), but http://codespeak.net/svn/py/dist/ basically contains 0.9.0-beta (py.__package__.version says so). If you check it out, and give feedback on the docs and if it's working for you, that's be great. Monday evening or tuesday i'd like to release, puh! best, holger -- merlinux GmbH Steinbergstr. 42 31139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77) From grig at agilistas.org Tue Feb 13 17:47:00 2007 From: grig at agilistas.org (Grig Gheorghiu) Date: Tue, 13 Feb 2007 08:47:00 -0800 Subject: [py-dev] Download links don't work Message-ID: I was trying to download py lib 0.9.0 and the 2 links on http://codespeak.net/py/current/doc/download.html result in 404 errors: http://codespeak.net/download/py/py-0.9.0.tgz http://codespeak.net/download/py/py-0.9.0.zip Grig From holger at merlinux.de Tue Feb 13 17:56:09 2007 From: holger at merlinux.de (holger krekel) Date: Tue, 13 Feb 2007 17:56:09 +0100 Subject: [py-dev] Download links don't work In-Reply-To: References: Message-ID: <20070213165609.GW16146@solar.trillke> Hi Grig! On Tue, Feb 13, 2007 at 08:47 -0800, Grig Gheorghiu wrote: > I was trying to download py lib 0.9.0 and the 2 links on > http://codespeak.net/py/current/doc/download.html result in 404 > errors: > > http://codespeak.net/download/py/py-0.9.0.tgz > http://codespeak.net/download/py/py-0.9.0.zip yes, thanks for reporting. they are not uploaded yet (just py-0.9.0-beta.tar.gz). moreover, the "current" link does not reflect the up-to-date docs, rather http://codespeak.net/py/dist/download.html (and we are still out to fix linking problems on the web site this evening). I guess we should add a redirection from "current" to "dist", or maybe a symbolic link suffices. best, holger From holger at merlinux.de Wed Feb 14 00:36:38 2007 From: holger at merlinux.de (holger krekel) Date: Wed, 14 Feb 2007 00:36:38 +0100 Subject: [py-dev] Japanese Translation In-Reply-To: References: Message-ID: <20070213233638.GY16146@solar.trillke> Hi Atshushi! (hope it's correct to address you this way) thanks for telling! we are about to release 0.9 version tomorrow and it is great that you help by translating to Japanese! I am CCing Brian Dorsey (from Seattle / US) who also knows a bit of Japanese, and also the py-dev list to let people know. best & many thanks! holger On Wed, Feb 14, 2007 at 01:43 +0900, Atsushi Odagiri wrote: > Hi, Holger > > I'm Atushi Odagiri, Japanese Python user. > > I found py.test last week. > I think py.test is very simple and gracefull. > I try to translate the document of py.test to Japanse. > I translated the first chapter in my blog to intoroduce py.test to Japanese. > http://d.hatena.ne.jp/aodag/20070213/1171383937 > > Shoud I do the anything to make public translation? > > Sorry, poor English. > Thanks. > -- > /* > Atsushi Odagiri > http://d.hatena.ne.jp/aodag/ > http://ziki.com/people/aodag > mailto:aodagx at gmail.com > */ > -- merlinux GmbH Steinbergstr. 42 31139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77) From aodagx at gmail.com Wed Feb 14 05:36:44 2007 From: aodagx at gmail.com (Atsushi Odagiri) Date: Wed, 14 Feb 2007 13:36:44 +0900 Subject: [py-dev] Japanese Translation In-Reply-To: <20070213233638.GY16146@solar.trillke> References: <20070213233638.GY16146@solar.trillke> Message-ID: Hi all! > Hi Atshushi! (hope it's correct to address you this way) OK, it's my correct address. And I joint to py-dev ML. > thanks for telling! we are about to release 0.9 version > tomorrow and it is great that you help by translating > to Japanese! I am CCing Brian Dorsey (from Seattle / US) In Japanese, python is minor language. The excellent tools such as py.test will have it notice that python is excellent. I hope to be mainspring of Japanese Python comunity. thanks. 2007/2/14, holger krekel : > Hi Atshushi! (hope it's correct to address you this way) > > thanks for telling! we are about to release 0.9 version > tomorrow and it is great that you help by translating > to Japanese! I am CCing Brian Dorsey (from Seattle / US) > who also knows a bit of Japanese, and also the py-dev list > to let people know. > > best & many thanks! > > holger > > On Wed, Feb 14, 2007 at 01:43 +0900, Atsushi Odagiri wrote: > > Hi, Holger > > > > I'm Atushi Odagiri, Japanese Python user. > > > > I found py.test last week. > > I think py.test is very simple and gracefull. > > I try to translate the document of py.test to Japanse. > > I translated the first chapter in my blog to intoroduce py.test to Japanese. > > http://d.hatena.ne.jp/aodag/20070213/1171383937 > > > > Shoud I do the anything to make public translation? > > > > Sorry, poor English. > > Thanks. > > -- > > /* > > Atsushi Odagiri > > http://d.hatena.ne.jp/aodag/ > > http://ziki.com/people/aodag > > mailto:aodagx at gmail.com > > */ > > > > -- > merlinux GmbH Steinbergstr. 42 31139 Hildesheim > http://merlinux.de tel +49 5121 20800 75 (fax 77) > -- /* Atsushi Odagiri http://d.hatena.ne.jp/aodag/ http://ziki.com/people/aodag mailto:aodagx at gmail.com */ From holger at merlinux.de Wed Feb 14 16:56:00 2007 From: holger at merlinux.de (holger krekel) Date: Wed, 14 Feb 2007 16:56:00 +0100 Subject: [py-dev] py lib 0.9.0: py.test, distributed execution, microthreads ... Message-ID: <20070214155600.GF16146@solar.trillke> py lib 0.9.0: py.test, distributed execution, greenlets and more ====================================================================== Welcome to the 0.9.0 py lib release - a library aiming to support agile and test-driven python development on various levels. Main API/Tool Features: * py.test: cross-project testing tool with many advanced features * py.execnet: ad-hoc code distribution to SSH, Socket and local sub processes * py.magic.greenlet: micro-threads on standard CPython ("stackless-light") * py.path: path abstractions over local and subversion files * rich documentation of py's exported API * tested against Linux, OSX and partly against Win32, python 2.3-2.5 All these features and their API have extensive documentation, generated with the new "apigen", which we intend to make accessible for other python projects as well. Download/Install: http://codespeak.net/py/0.9.0/download.html Documentation/API: http://codespeak.net/py/0.9.0/index.html Work on the py lib has been partially funded by the European Union IST programme and by http://merlinux.de within the PyPy project. best, have fun and let us know what you think! holger krekel, Maciej Fijalkowski, Guido Wesdorp, Carl Friedrich Bolz From brian at dorseys.org Thu Feb 15 00:04:52 2007 From: brian at dorseys.org (Brian Dorsey) Date: Wed, 14 Feb 2007 15:04:52 -0800 Subject: [py-dev] py lib 0.9.0: py.test, distributed execution, microthreads ... In-Reply-To: <20070214155600.GF16146@solar.trillke> References: <20070214155600.GF16146@solar.trillke> Message-ID: <66e877b70702141504i5d92a3e9mc3767f6a4576df79@mail.gmail.com> On 2/14/07, holger krekel wrote: > py lib 0.9.0: py.test, distributed execution, greenlets and more > ====================================================================== > > Welcome to the 0.9.0 py lib release - a library aiming to > support agile and test-driven python development on various levels. Yea! This is great news everyone! As someone who uses py.test every day, please accept my great thanks for all the work everyone put in to make this happen! Take care, -Brian From marian.schubert at gmail.com Thu Feb 15 14:49:26 2007 From: marian.schubert at gmail.com (Marian Schubert) Date: Thu, 15 Feb 2007 14:49:26 +0100 Subject: [py-dev] py.test: setup/teardown bugs Message-ID: Hello, there are 2 files attachment. Both should be easly used to reproduce bugs i found using py.test (which is great tool and i thank everyone who created/contributed to it). test_fail.py - both tests should fail because teardown_method is failing test_output.py - there is output of teardown method of previous test in current test's recorded output which i believe shouldn't be there cu, MS -------------- next part -------------- A non-text attachment was scrubbed... Name: test_fail.py Type: text/x-python Size: 239 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_output.py Type: text/x-python Size: 323 bytes Desc: not available URL: From Michael at Hipp.com Fri Feb 16 03:01:25 2007 From: Michael at Hipp.com (Michael Hipp) Date: Thu, 15 Feb 2007 20:01:25 -0600 Subject: [py-dev] Newbie with couple of questions Message-ID: <45D51075.4010801@Hipp.com> I'm looking seriously at py.test for my testing needs. Couple of questions: - Is there a "Users" list somewhere? (I wouldn't want to clog up a dev list with lots of messages like this one.) - Can test_ files be kept in a subdirectory of the project (i.e. keep tests in /projects/myproj/tests rather than in /projects/myproj)? - Is there a mechanism for detecting messages (in similar manner to detecting exceptions) when using a publish-subscribe scheme to decouple the MVC pieces in an application? Specifically I'm using lib.pubsub from wxPython. Thanks, Michael Hipp Heber Springs, Arkansas, USA From fijal at genesilico.pl Fri Feb 16 10:27:03 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Fri, 16 Feb 2007 10:27:03 +0100 Subject: [py-dev] Newbie with couple of questions In-Reply-To: <45D51075.4010801@Hipp.com> References: <45D51075.4010801@Hipp.com> Message-ID: <45D578E7.8010101@genesilico.pl> Michael Hipp wrote: > I'm looking seriously at py.test for my testing needs. Couple of questions: > Nice :) > - Is there a "Users" list somewhere? (I wouldn't want to clog up a dev list > with lots of messages like this one.) > Nope, but there is #pylib IRC channel on freenode. You're welcome to send posts here. > - Can test_ files be kept in a subdirectory of the project (i.e. keep tests in > /projects/myproj/tests rather than in /projects/myproj)? > Yes, they could be in any subdirectory of place where you execute py.test (even path would be right). In pylib itself tests are usually in testing subdirectory of each directory. > - Is there a mechanism for detecting messages (in similar manner to detecting > exceptions) when using a publish-subscribe scheme to decouple the MVC pieces > in an application? Specifically I'm using lib.pubsub from wxPython. > There is no such mechanism. Although I think that it's quite easy to create one (even in your project directory using conftest.py magic) Cheers, Fijal From holger at merlinux.de Fri Feb 16 10:32:15 2007 From: holger at merlinux.de (holger krekel) Date: Fri, 16 Feb 2007 10:32:15 +0100 Subject: [py-dev] Newbie with couple of questions In-Reply-To: <45D51075.4010801@Hipp.com> References: <45D51075.4010801@Hipp.com> Message-ID: <20070216093215.GX16146@solar.trillke> Hi Michael! On Thu, Feb 15, 2007 at 20:01 -0600, Michael Hipp wrote: > I'm looking seriously at py.test for my testing needs. Couple of questions: > > - Is there a "Users" list somewhere? (I wouldn't want to clog up a dev list > with lots of messages like this one.) it's fine to use py-dev for it! > - Can test_ files be kept in a subdirectory of the project (i.e. keep tests in > /projects/myproj/tests rather than in /projects/myproj)? yes, but make sure that tests/ has an (empty) __init__.py file. > - Is there a mechanism for detecting messages (in similar manner to detecting > exceptions) when using a publish-subscribe scheme to decouple the MVC pieces > in an application? Specifically I'm using lib.pubsub from wxPython. I don't know this particular one. You may extend py.test with a conftest.py file (see py/doc/impl-test.txt for info on how to get started on this). best, holger From marian.schubert at gmail.com Fri Feb 16 11:52:09 2007 From: marian.schubert at gmail.com (Marian Schubert) Date: Fri, 16 Feb 2007 11:52:09 +0100 Subject: [py-dev] py.test: setup/teardown bugs In-Reply-To: References: Message-ID: patch is in attachment. Don't know if it's best way how to solve this problem but it works and doesnt break any py.test tests :) cu, Maio On 2/15/07, Marian Schubert wrote: > Hello, > > there are 2 files attachment. Both should be easly used to reproduce > bugs i found using py.test (which is great tool and i thank everyone > who created/contributed to it). > > test_fail.py - both tests should fail because teardown_method is failing > test_output.py - there is output of teardown method of previous test > in current test's recorded output which i believe shouldn't be there > > > cu, > MS > > -------------- next part -------------- A non-text attachment was scrubbed... Name: teardown.patch Type: text/x-patch Size: 1259 bytes Desc: not available URL: From Michael at Hipp.com Fri Feb 16 15:48:36 2007 From: Michael at Hipp.com (Michael Hipp) Date: Fri, 16 Feb 2007 08:48:36 -0600 Subject: [py-dev] Newbie with couple of questions In-Reply-To: <20070216093215.GX16146@solar.trillke> References: <45D51075.4010801@Hipp.com> <20070216093215.GX16146@solar.trillke> Message-ID: <45D5C444.8090900@Hipp.com> holger krekel wrote: > On Thu, Feb 15, 2007 at 20:01 -0600, Michael Hipp wrote: >> I'm looking seriously at py.test for my testing needs. Couple of questions: >> >> - Is there a "Users" list somewhere? (I wouldn't want to clog up a dev list >> with lots of messages like this one.) > > it's fine to use py-dev for it! > >> - Can test_ files be kept in a subdirectory of the project (i.e. keep tests in >> /projects/myproj/tests rather than in /projects/myproj)? > > yes, but make sure that tests/ has an (empty) __init__.py file. > >> - Is there a mechanism for detecting messages (in similar manner to detecting >> exceptions) when using a publish-subscribe scheme to decouple the MVC pieces >> in an application? Specifically I'm using lib.pubsub from wxPython. > > I don't know this particular one. You may extend py.test with > a conftest.py file (see py/doc/impl-test.txt for info on how > to get started on this). Thanks, holger and Maciek. I'm checking it out of svn now. Michael From Michael at Hipp.com Sat Feb 17 04:58:26 2007 From: Michael at Hipp.com (Michael Hipp) Date: Fri, 16 Feb 2007 21:58:26 -0600 Subject: [py-dev] Testing publish-subscribe apps Message-ID: <45D67D62.5010703@Hipp.com> In my previous question I asked about testing applications that use a publish-subscribe mechanism. I've done a simple app and tester to prove I can make it work. I'm posting it here in case it might help someone else. I'd also like to invite critique as this is my first attempt at using py.test. (I'll be doing a *lot* of this when I test my real application.) Thanks, Michael --- The app being tested -------------------------------- # FILE: myapp.py from wx.lib.pubsub import Publisher myTestTopic = "my_test_topic" # A publisher topic def DoSomething(): # Send a message with a tuple of data Publisher.sendMessage(myTestTopic, (1,2,3)) --- The app being tested -------------------------------- # FILE: test_myapp.py from wx.lib.pubsub import Publisher # wxPython publish-subscribe module from myapp import DoSomething, myTestTopic # myapp.py # If someone can tell me how to not need these module-level # globals I'm all ears gotTestTopic = False # Indicates we received the test topic message testTopicData = None # The data we got with the test topic message def setup_module(module): '''This sets certain state specific to the execution of this module.''' # Subscribe to the test topic message Publisher.subscribe(TestTopicReceiver, myTestTopic) def test_DoSomething(): assert not gotTestTopic # Make sure there is no trickery assert testTopicData is None DoSomething() # This is "myapp" assert gotTestTopic # Now we should have it assert len(testTopicData) == 3 # Verify the data also def TestTopicReceiver(msg): '''Receives the test topic message and sets global vars to be read in the test routine.''' global gotTestTopic, testTopicData if msg.topic[0] == myTestTopic: # Make sure it's really our topic gotTestTopic = True testTopicData = msg.data # The data payload in the msg --- End ---- From fijal at genesilico.pl Sun Feb 18 14:02:46 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Sun, 18 Feb 2007 14:02:46 +0100 Subject: [py-dev] py.test: setup/teardown bugs In-Reply-To: References: Message-ID: <45D84E76.3040605@genesilico.pl> Marian Schubert wrote: > patch is in attachment. Don't know if it's best way how to solve this > problem but it works and doesnt break any py.test tests :) > Hi! I've reviewed your patch. Seems indeed to solve a probelm a bit, but doesn't solve a problem in general (what's with setup_class?). I guess we can come up with better solution, but of course you're welcome to participate in that! Particularly I would not like to specialcase Function there and probably teardown happening just after function run sounds like better idea than in front of next one. Also having teardown in finally: doesn't really solve the problem, because if you've got errors in both your test and teardown that the chance is quite high that you want to see only first one. Thanks for your effort! Cheers, Fijal From holger at merlinux.de Sun Feb 18 14:39:05 2007 From: holger at merlinux.de (holger krekel) Date: Sun, 18 Feb 2007 14:39:05 +0100 Subject: [py-dev] Testing publish-subscribe apps In-Reply-To: <45D67D62.5010703@Hipp.com> References: <45D67D62.5010703@Hipp.com> Message-ID: <20070218133905.GR16146@solar.trillke> Hi Michael, On Fri, Feb 16, 2007 at 21:58 -0600, Michael Hipp wrote: > In my previous question I asked about testing applications that use a > publish-subscribe mechanism. I've done a simple app and tester to prove I can > make it work. I'm posting it here in case it might help someone else. I'd also > like to invite critique as this is my first attempt at using py.test. (I'll be > doing a *lot* of this when I test my real application.) > > Thanks, > Michael > > --- The app being tested -------------------------------- > # FILE: myapp.py > > from wx.lib.pubsub import Publisher > > myTestTopic = "my_test_topic" # A publisher topic > > def DoSomething(): > # Send a message with a tuple of data > Publisher.sendMessage(myTestTopic, (1,2,3)) > --- The app being tested -------------------------------- > # FILE: test_myapp.py > > from wx.lib.pubsub import Publisher # wxPython publish-subscribe module > from myapp import DoSomething, myTestTopic # myapp.py > > # If someone can tell me how to not need these module-level > # globals I'm all ears > gotTestTopic = False # Indicates we received the test topic message > testTopicData = None # The data we got with the test topic message > > def setup_module(module): > '''This sets certain state specific to the execution of this module.''' > # Subscribe to the test topic message > Publisher.subscribe(TestTopicReceiver, myTestTopic) a few notes: * i have no clue about wxpython :) * I prefer to have test and code-being-tested separate from each other, so myTestTopic would be better to live in the testfile. * i guess you can avoid module globals by using test classes (see e.g. http://codespeak.net/py/dist/test.html#id17) maybe something like (untested): class TestMyApp: def setup_method(self, method): self.topic = "my_test_topic" # + method.__name__ self.received = [] Publisher.subscribe(self.topic, self.received.append) def teardown_method(self, method): # don't know if wx has it: Publisher.unsubscribe(self.topic, self.received.append) def test_dosomething(self): assert not self.received DoSomething() assert len(self.received) == 1 msg = self.received[0] assert msg.topic == self.topic assert len(msg.data) == 3 # and so one hope it helps, have fun, holger > def test_DoSomething(): > assert not gotTestTopic # Make sure there is no trickery > assert testTopicData is None > DoSomething() # This is "myapp" > assert gotTestTopic # Now we should have it > assert len(testTopicData) == 3 # Verify the data also > > def TestTopicReceiver(msg): > '''Receives the test topic message and sets global vars to be read in > the test routine.''' > global gotTestTopic, testTopicData > if msg.topic[0] == myTestTopic: # Make sure it's really our topic > gotTestTopic = True > testTopicData = msg.data # The data payload in the msg > > --- End ---- > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- merlinux GmbH Steinbergstr. 42 31139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77) From schmir at gmail.com Tue Feb 20 10:20:06 2007 From: schmir at gmail.com (Ralf Schmitt) Date: Tue, 20 Feb 2007 10:20:06 +0100 Subject: [py-dev] py.test and twisted Message-ID: <932f8baf0702200120k2d55fc58kd23afd3f6ae4d36c@mail.gmail.com> Hi all, I've made py.test work with the twisted framework using greenlets to switch between twisted's mainloop and py.test's "mainloop". (see attached file). It currently uses monkeypatching to change py.test.Item's execute function. Currently missing is the ability to return twisted deferreds from setup and teardown methods. I could monkeypatch py.test even more, but I'd rather have a method to hook into py.test, and intercept any calls to user supplied functions (i.e. teardown, setup, and test methods). Any chance to get such changes integrated into py.test? I'd be willing to write them on my own and would also be glad to have the py.test.twisted script be included into py.test. - Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: py.test.twisted Type: application/octet-stream Size: 1706 bytes Desc: not available URL: From beacybooks at bigpond.com Fri Feb 23 02:39:43 2007 From: beacybooks at bigpond.com (Tom Harris) Date: Fri, 23 Feb 2007 12:39:43 +1100 Subject: [py-dev] Test directories for py.test Message-ID: <45DE45DF.9090607@bigpond.com> Greetings, I like to have my tests in a subdirectory for a project, so directory 'foo' would have a subdirectory 'test'. The tests in 'test' should be able to load module foo.py in it's parent directory, with a sys.path.insert(0, '..'). That's the way I did it with unittest anyway. Example below fails unless I insert a '.' instead of '..' into sys.path. file 'foo/foo.py': def a(): return 1 file 'foo/test/test_foo.py': import sys sys.path.insert(0, '..') import foo def test_1(): assert foo.a() == 1 Now I'm quite happy to type import sys; sys.path.insert(0, '.') at the head of all my test files, but am I missing something? -- Tom Harris BeacyBooks From Michael at Hipp.com Fri Feb 23 02:55:28 2007 From: Michael at Hipp.com (Michael Hipp) Date: Thu, 22 Feb 2007 19:55:28 -0600 Subject: [py-dev] Test directories for py.test In-Reply-To: <45DE45DF.9090607@bigpond.com> References: <45DE45DF.9090607@bigpond.com> Message-ID: <45DE4990.7000908@Hipp.com> Tom Harris wrote: > I like to have my tests in a subdirectory for a project, so directory > 'foo' would have a subdirectory 'test'. The tests in 'test' should be > able to load module foo.py in it's parent directory, with a > sys.path.insert(0, '..'). That's the way I did it with unittest anyway. > Example below fails unless I insert a '.' instead of '..' into sys.path. > > file 'foo/foo.py': > def a(): return 1 > > file 'foo/test/test_foo.py': > import sys > sys.path.insert(0, '..') > import foo > > def test_1(): > assert foo.a() == 1 > > Now I'm quite happy to type import sys; sys.path.insert(0, '.') at the > head of all my test files, but am I missing something? I'm pretty new at this, but here's what I have at the head of all my test/test_foo.py files: import sys sys.path.append('..') It works. I wonder if inserting it at the 0 spot in the list is the problem (as opposed to the end like I'm doing)? The first item in the path list appears to be something special as I read the docs. Michael From marian.schubert at gmail.com Fri Feb 23 15:00:59 2007 From: marian.schubert at gmail.com (Marian Schubert) Date: Fri, 23 Feb 2007 15:00:59 +0100 Subject: [py-dev] py.test: bug py.test.raises doesn't fail when using webserver Message-ID: Hello, test is in attachment. $ py.test -v test_web.py + testmodule: /home/maio/tmp/test_web.py test_web.py:3 test_raises FAIL (0.00) $ py.test -wr test_web.py Tests [FINISHED 1 run, 0 failures, 0 skipped] cu, Maio -------------- next part -------------- A non-text attachment was scrubbed... Name: test_web.py Type: text/x-python Size: 75 bytes Desc: not available URL: From cfbolz at gmx.de Fri Feb 23 15:14:42 2007 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Fri, 23 Feb 2007 15:14:42 +0100 Subject: [py-dev] Test directories for py.test In-Reply-To: <45DE45DF.9090607@bigpond.com> References: <45DE45DF.9090607@bigpond.com> Message-ID: <45DEF6D2.3090002@gmx.de> Hi Tom! Tom Harris wrote: > I like to have my tests in a subdirectory for a project, so directory > 'foo' would have a subdirectory 'test'. The tests in 'test' should be > able to load module foo.py in it's parent directory, with a > sys.path.insert(0, '..'). That's the way I did it with unittest anyway. > Example below fails unless I insert a '.' instead of '..' into sys.path. > > file 'foo/foo.py': > def a(): return 1 > > file 'foo/test/test_foo.py': > import sys > sys.path.insert(0, '..') > import foo > > def test_1(): > assert foo.a() == 1 > > Now I'm quite happy to type import sys; sys.path.insert(0, '.') at the > head of all my test files, but am I missing something? Since this is quite a common problem, There is a built-in solution in py.test :-). The idea is the following: py.test inserts a certain path into sys.path. Which path that is, is determined by walking up the directories starting from the test dir until it finds a directory that does not have an __init__.py file. So what you could do: file 'foo/__init__.py': # empty or whatever file 'foo/bar.py': def a(): return 1 file 'foo/test/__init__.py': # empty or whatever file 'foo/test/test_bar.py': from foo import bar def test_a(): assert bar.a() == 1 This allows you to have a deeper directory hierarchy and always the right directory is inserted (as long as you have __init__.py files everywhere but in the dir above your project). Cheers, Carl Friedrich From fijal at genesilico.pl Fri Feb 23 15:20:03 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Fri, 23 Feb 2007 15:20:03 +0100 Subject: [py-dev] Test directories for py.test In-Reply-To: <45DEF6D2.3090002@gmx.de> References: <45DE45DF.9090607@bigpond.com> <45DEF6D2.3090002@gmx.de> Message-ID: <45DEF813.8030301@genesilico.pl> Carl Friedrich Bolz wrote: > Hi Tom! > > Tom Harris wrote: > > I like to have my tests in a subdirectory for a project, so directory > > 'foo' would have a subdirectory 'test'. The tests in 'test' should be > > able to load module foo.py in it's parent directory, with a > > sys.path.insert(0, '..'). That's the way I did it with unittest anyway. > > Example below fails unless I insert a '.' instead of '..' into sys.path. > > > > file 'foo/foo.py': > > def a(): return 1 > > > > file 'foo/test/test_foo.py': > > import sys > > sys.path.insert(0, '..') > > import foo > > > > def test_1(): > > assert foo.a() == 1 > > > > Now I'm quite happy to type import sys; sys.path.insert(0, '.') at the > > head of all my test files, but am I missing something? > > Since this is quite a common problem, There is a built-in solution in > py.test :-). The idea is the following: py.test inserts a certain path into > sys.path. Which path that is, is determined by walking up the > directories starting from the test dir until it finds a directory that > does not have an __init__.py file. So what you could do: > > file 'foo/__init__.py': > # empty or whatever > > file 'foo/bar.py': > def a(): return 1 > > file 'foo/test/__init__.py': > # empty or whatever > > file 'foo/test/test_bar.py': > from foo import bar > > def test_a(): > assert bar.a() == 1 > > > This allows you to have a deeper directory hierarchy and always the > right directory is inserted (as long as you have __init__.py files > everywhere but in the dir above your project). > > Also note that you usually need to use absolute imports than (as in example above) as well as you cannot have __init__.py in the same directory where foo is located. From fijal at genesilico.pl Fri Feb 23 15:28:49 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Fri, 23 Feb 2007 15:28:49 +0100 Subject: [py-dev] py.test: bug py.test.raises doesn't fail when using webserver In-Reply-To: References: Message-ID: <45DEFA21.4080105@genesilico.pl> Marian Schubert wrote: > Hello, > > test is in attachment. > > $ py.test -v test_web.py > + testmodule: /home/maio/tmp/test_web.py > test_web.py:3 test_raises FAIL (0.00) > > $ py.test -wr test_web.py > Tests [FINISHED 1 run, 0 failures, 0 skipped] > > cu, > Maio > ------------------------------------------------------------------------ > > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > Thanks, fixed From Michael at Hipp.com Fri Feb 23 15:37:15 2007 From: Michael at Hipp.com (Michael Hipp) Date: Fri, 23 Feb 2007 08:37:15 -0600 Subject: [py-dev] Test directories for py.test In-Reply-To: <45DEF6D2.3090002@gmx.de> References: <45DE45DF.9090607@bigpond.com> <45DEF6D2.3090002@gmx.de> Message-ID: <45DEFC1B.2030602@Hipp.com> Carl Friedrich Bolz wrote: > Hi Tom! > > Tom Harris wrote: > > I like to have my tests in a subdirectory for a project, so directory > > 'foo' would have a subdirectory 'test'. The tests in 'test' should be > > able to load module foo.py in it's parent directory, with a > > sys.path.insert(0, '..'). That's the way I did it with unittest anyway. > > Example below fails unless I insert a '.' instead of '..' into sys.path. > > > > file 'foo/foo.py': > > def a(): return 1 > > > > file 'foo/test/test_foo.py': > > import sys > > sys.path.insert(0, '..') > > import foo > > > > def test_1(): > > assert foo.a() == 1 > > > > Now I'm quite happy to type import sys; sys.path.insert(0, '.') at the > > head of all my test files, but am I missing something? > > Since this is quite a common problem, There is a built-in solution in > py.test :-). The idea is the following: py.test inserts a certain path into > sys.path. Which path that is, is determined by walking up the > directories starting from the test dir until it finds a directory that > does not have an __init__.py file. So what you could do: > > file 'foo/__init__.py': > # empty or whatever > > file 'foo/bar.py': > def a(): return 1 > > file 'foo/test/__init__.py': > # empty or whatever > > file 'foo/test/test_bar.py': > from foo import bar > > def test_a(): > assert bar.a() == 1 > > > This allows you to have a deeper directory hierarchy and always the > right directory is inserted (as long as you have __init__.py files > everywhere but in the dir above your project). Thanks for this. I didn't know any of that. But it doesn't seem to work unless the import statements are written exactly as above. For example, if you change the 3rd from last line to: from bar import a it says "FAILED TO LOAD MODULE". So the compromise, I guess, is to write it as from foo.bar import a A bit uglier and more typing but superior to the sys.path append/insert business. Thanks again, Michael From Michael at Hipp.com Sat Feb 24 18:31:36 2007 From: Michael at Hipp.com (Michael Hipp) Date: Sat, 24 Feb 2007 11:31:36 -0600 Subject: [py-dev] How best to notify modules? Message-ID: <45E07678.7090707@Hipp.com> What's the best technique for this? My current project uses lots of timestamps ( i.e now(), today() ) but this causes lots of things to return different results with every run. So for the cases where the module under test needs to return results that are binary repeatable with every run, I want to centralize all my calls to the above functions in one place and have them return a predetermined value when under test. So how best to communicate to a module that it is under test and a few certain things need to modify their behavior slightly? Just looking for "best practices" here. Thanks, Michael From fijal at genesilico.pl Sat Feb 24 18:35:52 2007 From: fijal at genesilico.pl (Maciek Fijalkowski) Date: Sat, 24 Feb 2007 18:35:52 +0100 Subject: [py-dev] How best to notify modules? In-Reply-To: <45E07678.7090707@Hipp.com> References: <45E07678.7090707@Hipp.com> Message-ID: <45E07778.7060307@genesilico.pl> Michael Hipp wrote: > What's the best technique for this? > > My current project uses lots of timestamps ( i.e now(), today() ) but this > causes lots of things to return different results with every run. So for the > cases where the module under test needs to return results that are binary > repeatable with every run, I want to centralize all my calls to the above > functions in one place and have them return a predetermined value when under test. > > So how best to communicate to a module that it is under test and a few certain > things need to modify their behavior slightly? > > Just looking for "best practices" here. > > Thanks, > Michael > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > I would go for import foo def setup_module(mod): try: old_now = foo.now foo.now = a_day .... finally: foo.now = old_now From Michael at Hipp.com Sat Feb 24 20:23:11 2007 From: Michael at Hipp.com (Michael Hipp) Date: Sat, 24 Feb 2007 13:23:11 -0600 Subject: [py-dev] How best to notify modules? In-Reply-To: <45E07778.7060307@genesilico.pl> References: <45E07678.7090707@Hipp.com> <45E07778.7060307@genesilico.pl> Message-ID: <45E0909F.8090004@Hipp.com> Maciek Fijalkowski wrote: > Michael Hipp wrote: >> What's the best technique for this? >> >> My current project uses lots of timestamps ( i.e now(), today() ) but >> this causes lots of things to return different results with every run. >> So for the cases where the module under test needs to return results >> that are binary repeatable with every run, I want to centralize all my >> calls to the above functions in one place and have them return a >> predetermined value when under test. >> >> So how best to communicate to a module that it is under test and a few >> certain things need to modify their behavior slightly? >> >> Just looking for "best practices" here. > I would go for > > import foo > > def setup_module(mod): > try: > old_now = foo.now > foo.now = a_day > .... > finally: > foo.now = old_now Thanks! Michael From beacybooks at bigpond.com Mon Feb 26 04:13:22 2007 From: beacybooks at bigpond.com (Tom Harris) Date: Mon, 26 Feb 2007 14:13:22 +1100 Subject: [py-dev] Generative tests & teardown_method() In-Reply-To: <45DEFC1B.2030602@Hipp.com> References: <45DE45DF.9090607@bigpond.com> <45DEF6D2.3090002@gmx.de> <45DEFC1B.2030602@Hipp.com> Message-ID: <45E25052.50400@bigpond.com> Greetings, Thanks for all the help on my test directories question, now I have another about generative tests. When a series of such tests are run, the teardown_method() method is not run until the generator function that makes them is done. This was not what I expected or wanted to happen, as the generated tests each open a network connection, and after about 50 or so, my machine was suffering a bit under the load! Would it be better if a generator called setup/teardown once for _each_ generated test? Tom Harris BeacyBooks > >