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
--
_______________________________________________
py-dev mailing list
py-dev@codespeak.net
http://codespeak.net/mailman/listinfo/py-dev
