That's a big help. I had bypassed the xUnit docs because the name sounded like a feature in which I wasn't interested (just because of the name).
Silly me. Thanks for the reference. > -----Original Message----- > From: holger krekel [mailto:hol...@merlinux.eu] > Sent: Thursday, 05 August, 2010 11:29 > To: Jason R. Coombs > Cc: py-dev@codespeak.net > Subject: Re: [py-dev] feedback on py.test discovery/setup/process > documentation > > Hi Jason, > > thanks for the feedback, i appreciate it. I am aware that documentation > needs some love - i actually plan to port it to sphinx (which has builtin search > apart from other nicities) and add an example section. > > That being said, under > > http://codespeak.net/py/dist/test/features.html > > there is a link to "xUnit style setup": > > http://codespeak.net/py/dist/test/xunit_setup.html > > which may help a bit regarding the hooks. It doesn't mention > pytest_configure which is mentioned here: > > http://codespeak.net/py/dist/test/customize.html > > ... so i guess it's true that things should be organised more according to usage > patterns / needs rather than the structure of the implementation. Oh, and > feel free to write blog posts about things you found so we can link them :) > > best, > holger > > On Thu, Aug 05, 2010 at 08:05 -0700, Jason R. Coombs wrote: > > I was espousing the joys of py.test at a recent #DCPython meetup. I > > found, however, that I'm not the only person frustrated by the lack of > > documentation on the basic process py.test uses to discover, setup, > > and conduct tests. > > > > > > > > There's mention here and there of setup/teardown methods, and their > > names are fairly intuitive, but I can't find that they're documented > > anywhere. It would be nice if there was a half-page document on the > > process py.test uses to conduct a single test. something like: > > > > > > > > # globally > > > > Run pytest_configure > > > > For each test module matching test_*.py: > > > > Run setup_module(module object) > > > > For each class in module.Test*: > > > > skip if it's not a valid test class (i.e. > > has an __init__ method) > > > > Run setup_class(class_object) [p.s. > > why doesn't setup_class have to be a classmethod?] > > > > For each method: > > > > Run > > setup_method(instance, > > method) > > > > Run test > > > > Run teardown_method > > > > Run teardown_class > > > > . > > > > > > > > I've discovered all of this through trial and error (and tracking down > > examples here and there). For example, I couldn't find setup_method > > documented anywhere, even though I knew what I wanted (a setup for > > each test to be run). > > > > > > > > Also, it would be nice to have some clarification on which classes > > will be discovered. I was recently bitten by an interesting feature. > > If a test class has an __init__ method, it will not be run as a test. > > For one test, I was using the __init__ method to define setup for each > > instance of the test. It turns out that by using setup_method instead > > of __init__, it did precisely what I wanted, but I went several weeks > > thinking my tests were running, when they were being silently skipped. > > > > > > > > I realize that all of this seems a little nitpicky. Truly, I love > > py.test, but I have to agree with my colleagues that it's a little > > difficult getting to know the basics. It doesn't help matters that > > because of the name, it's difficult to search the web for py.test resources. > > > > > > > > If you have any suggestions on how I might have learned these details > > other than through trial-and-error, please point me to them. > > > > > > > > Regards, > > > > > > > > Jason > > > > > > > _______________________________________________ > > py-dev mailing list > > py-dev@codespeak.net > > http://codespeak.net/mailman/listinfo/py-dev > > > --
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
