[pytest-dev] What is the best path to walk in building a mental model of the py.test codebase?

Brianna Laugher brianna.laugher at gmail.com
Sun Jul 26 17:01:18 CEST 2015


Hi Andrew,

I think I don't have a particularly clear understanding of the structure of
pytest so I am also interested in this question :)

One thing is that the plugin system is quite deeply embedded in pytest,
which means you can write powerful plugins via hooks, but also it makes the
code flow a little indirect. Also because pytest aims to be able to run
other kinds of tests, it's quite flexible, which means handling a lot of
cases in a kind of generic way, which is hard to understand at first.

At Europython Floris talked about pluggy which is pytest's plugin system, I
think it offers some insight into pytest internals. Slides are here:
http://devork.be/talks/pluggy/pluggy.html
Video here:
https://www.youtube.com/watch?feature=player_detailpage&v=0u__PVN2PX0#t=6204
(should start at around 1:43:00)

Regarding -k and -m, I find it best to use them with --collectonly first to
make sure it is selecting the tests I think it is. I guess you mean the
test selection differs to what you expect, rather than it *always* selects
all tests.

It's kind of known that test selection doesn't always work as expected,
especially with parametrized tests. Nonetheless if you have some specific
cases you want to raise as an issue you're welcome to do so. (They may be
helpful as test cases if the test selection syntax is rewritten)

cheers,
Brianna



On 26 July 2015 at 05:20, Andrew Farrell <amfarrell at mit.edu> wrote:

> Hi Folks,
>
> I'm starting out reading through the py.test codebase in order to:
> 1) Educate myself on how test frameworks are structured.
> 2) Experiment with using pieces of the_silver_searcher
> <https://github.com/ggreer/the_silver_searcher> or reducing the number of
> missed stat() calls python makes to increase the speed of test discovery.
> 3) Be able to figure out answers to specific questions I have such as "How
> do I get specific subsets of tests to run when the -k or -m options don't
> seem to actually prevent tests from being run?"
>
> If it isn't too much trouble, does anyone here suggestions for what the
> best order to follow when reading the codebase? Any contributors that could
> retell how they built a clear mental model of it when they started?
>
> Thank you,
> Andrew
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>


-- 
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150726/c4e956ec/attachment.html>


More information about the pytest-dev mailing list