<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>pytest-2.3: reasoning for fixture/funcarg evolution</title> <link rel="stylesheet" href="_static/sphinxdoc.css" type="text/css" /> <link rel="stylesheet" href="_static/pygments.css" type="text/css" /> <script type="text/javascript"> var DOCUMENTATION_OPTIONS = { URL_ROOT: '', VERSION: '2.3.4.1', COLLAPSE_INDEX: false, FILE_SUFFIX: '.html', HAS_SOURCE: true }; </script> <script type="text/javascript" src="_static/jquery.js"></script> <script type="text/javascript" src="_static/underscore.js"></script> <script type="text/javascript" src="_static/doctools.js"></script> <link rel="top" title="None" href="index.html" /> <link rel="next" title="Release announcements" href="announce/index.html" /> <link rel="prev" title="Contact channels" href="contact.html" /> </head> <body> <div class="related"> <h3>Navigation</h3> <ul> <li class="right" style="margin-right: 10px"> <a href="announce/index.html" title="Release announcements" accesskey="N">next</a></li> <li class="right" > <a href="contact.html" title="Contact channels" accesskey="P">previous</a> |</li> <li><a href="contents.html">pytest-2.3.4.1</a> »</li> <g:plusone></g:plusone> </ul> </div> <div class="sphinxsidebar"> <div class="sphinxsidebarwrapper"> <div id="searchbox" style="display: none"> <form class="search" action="search.html" method="get"> <input type="text" name="q" size="18" /> <input type="submit" value="Search" /> <input type="hidden" name="check_keywords" value="yes" /> <input type="hidden" name="area" value="default" /> </form> </div> <script type="text/javascript">$('#searchbox').show(0);</script> <h3>quicklinks</h3> <div style="text-align: left; font-size: 100%; vertical-align: middle;"> <table> <tr> <td> <a href="index.html">home</a> </td><td> <a href="contents.html">TOC/contents</a> </td></tr><tr><td> <a href="getting-started.html">install</a> </td><td> <a href="changelog.html">changelog</a> </td></tr><tr><td> <a href="example/index.html">examples</a> </td><td> <a href="customize.html">customize</a> </td></tr><tr><td> <a href="https://bitbucket.org/hpk42/pytest/issues?status=new&status=open">issues[bb]</a> </td><td> <a href="contact.html">contact</a> </td></tr></table> </div> <h3><a href="contents.html">Table Of Contents</a></h3> <ul> <li><a class="reference internal" href="#">pytest-2.3: reasoning for fixture/funcarg evolution</a><ul> <li><a class="reference internal" href="#shortcomings-of-the-previous-pytest-funcarg-mechanism">Shortcomings of the previous <tt class="docutils literal"><span class="pre">pytest_funcarg__</span></tt> mechanism</a></li> <li><a class="reference internal" href="#direct-scoping-of-fixture-funcarg-factories">Direct scoping of fixture/funcarg factories</a></li> <li><a class="reference internal" href="#direct-parametrization-of-funcarg-resource-factories">Direct parametrization of funcarg resource factories</a></li> <li><a class="reference internal" href="#no-pytest-funcarg-prefix-when-using-fixture-decorator">No <tt class="docutils literal"><span class="pre">pytest_funcarg__</span></tt> prefix when using @fixture decorator</a></li> <li><a class="reference internal" href="#solving-per-session-setup-autouse-fixtures">solving per-session setup / autouse fixtures</a></li> <li><a class="reference internal" href="#funcargs-fixture-discovery-now-happens-at-collection-time">funcargs/fixture discovery now happens at collection time</a></li> <li><a class="reference internal" href="#conclusion-and-compatibility-notes">Conclusion and compatibility notes</a></li> </ul> </li> </ul> <h4>Previous topic</h4> <p class="topless"><a href="contact.html" title="previous chapter">Contact channels</a></p> <h4>Next topic</h4> <p class="topless"><a href="announce/index.html" title="next chapter">Release announcements</a></p> </div> </div> <div class="document"> <div class="documentwrapper"> <div class="bodywrapper"> <div class="body"> <div class="section" id="pytest-2-3-reasoning-for-fixture-funcarg-evolution"> <span id="funcargcompare"></span><h1>pytest-2.3: reasoning for fixture/funcarg evolution<a class="headerlink" href="#pytest-2-3-reasoning-for-fixture-funcarg-evolution" title="Permalink to this headline">¶</a></h1> <p><strong>Target audience</strong>: Reading this document requires basic knowledge of python testing, xUnit setup methods and the (previous) basic pytest funcarg mechanism, see <a class="reference external" href="http://pytest.org/2.2.4/funcargs.html">http://pytest.org/2.2.4/funcargs.html</a> If you are new to pytest, then you can simply ignore this section and read the other sections.</p> <div class="section" id="shortcomings-of-the-previous-pytest-funcarg-mechanism"> <h2>Shortcomings of the previous <tt class="docutils literal"><span class="pre">pytest_funcarg__</span></tt> mechanism<a class="headerlink" href="#shortcomings-of-the-previous-pytest-funcarg-mechanism" title="Permalink to this headline">¶</a></h2> <p>The pre pytest-2.3 funcarg mechanism calls a factory each time a funcarg for a test function is required. If a factory wants to re-use a resource across different scopes, it often used the <tt class="docutils literal"><span class="pre">request.cached_setup()</span></tt> helper to manage caching of resources. Here is a basic example how we could implement a per-session Database object:</p> <div class="highlight-python"><div class="highlight"><pre><span class="c"># content of conftest.py</span> <span class="k">class</span> <span class="nc">Database</span><span class="p">:</span> <span class="k">def</span> <span class="nf">__init__</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span> <span class="k">print</span> <span class="p">(</span><span class="s">"database instance created"</span><span class="p">)</span> <span class="k">def</span> <span class="nf">destroy</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span> <span class="k">print</span> <span class="p">(</span><span class="s">"database instance destroyed"</span><span class="p">)</span> <span class="k">def</span> <span class="nf">pytest_funcarg__db</span><span class="p">(</span><span class="n">request</span><span class="p">):</span> <span class="k">return</span> <span class="n">request</span><span class="o">.</span><span class="n">cached_setup</span><span class="p">(</span><span class="n">setup</span><span class="o">=</span><span class="n">DataBase</span><span class="p">,</span> <span class="n">teardown</span><span class="o">=</span><span class="k">lambda</span> <span class="n">db</span><span class="p">:</span> <span class="n">db</span><span class="o">.</span><span class="n">destroy</span><span class="p">,</span> <span class="n">scope</span><span class="o">=</span><span class="s">"session"</span><span class="p">)</span> </pre></div> </div> <p>There are several limitations and difficulties with this approach:</p> <ol class="arabic simple"> <li>Scoping funcarg resource creation is not straight forward, instead one must understand the intricate cached_setup() method mechanics.</li> <li>parametrizing the “db” resource is not straight forward: you need to apply a “parametrize” decorator or implement a <a class="reference internal" href="plugins.html#_pytest.hookspec.pytest_generate_tests" title="_pytest.hookspec.pytest_generate_tests"><tt class="xref py py-func docutils literal"><span class="pre">pytest_generate_tests()</span></tt></a> hook calling <a class="reference internal" href="parametrize.html#_pytest.python.Metafunc.parametrize" title="_pytest.python.Metafunc.parametrize"><tt class="xref py py-func docutils literal"><span class="pre">parametrize()</span></tt></a> which performs parametrization at the places where the resource is used. Moreover, you need to modify the factory to use an <tt class="docutils literal"><span class="pre">extrakey</span></tt> parameter containing <tt class="docutils literal"><span class="pre">request.param</span></tt> to the <tt class="xref py py-func docutils literal"><span class="pre">cached_setup()</span></tt> call.</li> <li>Multiple parametrized session-scoped resources will be active at the same time, making it hard for them to affect global state of the application under test.</li> <li>there is no way how you can make use of funcarg factories in xUnit setup methods.</li> <li>A non-parametrized fixture function cannot use a parametrized funcarg resource if it isn’t stated in the test function signature.</li> </ol> <p>All of these limitations are addressed with pytest-2.3 and its improved <a class="reference internal" href="fixture.html#fixture"><em>fixture mechanism</em></a>.</p> </div> <div class="section" id="direct-scoping-of-fixture-funcarg-factories"> <h2>Direct scoping of fixture/funcarg factories<a class="headerlink" href="#direct-scoping-of-fixture-funcarg-factories" title="Permalink to this headline">¶</a></h2> <p>Instead of calling cached_setup() with a cache scope, you can use the <a class="reference internal" href="fixture.html#id1"><em>@pytest.fixture</em></a> decorator and directly state the scope:</p> <div class="highlight-python"><div class="highlight"><pre><span class="nd">@pytest.fixture</span><span class="p">(</span><span class="n">scope</span><span class="o">=</span><span class="s">"session"</span><span class="p">)</span> <span class="k">def</span> <span class="nf">db</span><span class="p">(</span><span class="n">request</span><span class="p">):</span> <span class="c"># factory will only be invoked once per session -</span> <span class="n">db</span> <span class="o">=</span> <span class="n">DataBase</span><span class="p">()</span> <span class="n">request</span><span class="o">.</span><span class="n">addfinalizer</span><span class="p">(</span><span class="n">db</span><span class="o">.</span><span class="n">destroy</span><span class="p">)</span> <span class="c"># destroy when session is finished</span> <span class="k">return</span> <span class="n">db</span> </pre></div> </div> <p>This factory implementation does not need to call <tt class="docutils literal"><span class="pre">cached_setup()</span></tt> anymore because it will only be invoked once per session. Moreover, the <tt class="docutils literal"><span class="pre">request.addfinalizer()</span></tt> registers a finalizer according to the specified resource scope on which the factory function is operating.</p> </div> <div class="section" id="direct-parametrization-of-funcarg-resource-factories"> <h2>Direct parametrization of funcarg resource factories<a class="headerlink" href="#direct-parametrization-of-funcarg-resource-factories" title="Permalink to this headline">¶</a></h2> <p>Previously, funcarg factories could not directly cause parametrization. You needed to specify a <tt class="docutils literal"><span class="pre">@parametrize</span></tt> decorator on your test function or implement a <tt class="docutils literal"><span class="pre">pytest_generate_tests</span></tt> hook to perform parametrization, i.e. calling a test multiple times with different value sets. pytest-2.3 introduces a decorator for use on the factory itself:</p> <div class="highlight-python"><div class="highlight"><pre><span class="nd">@pytest.fixture</span><span class="p">(</span><span class="n">params</span><span class="o">=</span><span class="p">[</span><span class="s">"mysql"</span><span class="p">,</span> <span class="s">"pg"</span><span class="p">])</span> <span class="k">def</span> <span class="nf">db</span><span class="p">(</span><span class="n">request</span><span class="p">):</span> <span class="o">...</span> <span class="c"># use request.param</span> </pre></div> </div> <p>Here the factory will be invoked twice (with the respective “mysql” and “pg” values set as <tt class="docutils literal"><span class="pre">request.param</span></tt> attributes) and and all of the tests requiring “db” will run twice as well. The “mysql” and “pg” values will also be used for reporting the test-invocation variants.</p> <p>This new way of parametrizing funcarg factories should in many cases allow to re-use already written factories because effectively <tt class="docutils literal"><span class="pre">request.param</span></tt> was already used when test functions/classes were parametrized via <tt class="xref py py-func docutils literal"><span class="pre">parametrize(indirect=True)()</span></tt> calls.</p> <p>Of course it’s perfectly fine to combine parametrization and scoping:</p> <div class="highlight-python"><div class="highlight"><pre><span class="nd">@pytest.fixture</span><span class="p">(</span><span class="n">scope</span><span class="o">=</span><span class="s">"session"</span><span class="p">,</span> <span class="n">params</span><span class="o">=</span><span class="p">[</span><span class="s">"mysql"</span><span class="p">,</span> <span class="s">"pg"</span><span class="p">])</span> <span class="k">def</span> <span class="nf">db</span><span class="p">(</span><span class="n">request</span><span class="p">):</span> <span class="k">if</span> <span class="n">request</span><span class="o">.</span><span class="n">param</span> <span class="o">==</span> <span class="s">"mysql"</span><span class="p">:</span> <span class="n">db</span> <span class="o">=</span> <span class="n">MySQL</span><span class="p">()</span> <span class="k">elif</span> <span class="n">request</span><span class="o">.</span><span class="n">param</span> <span class="o">==</span> <span class="s">"pg"</span><span class="p">:</span> <span class="n">db</span> <span class="o">=</span> <span class="n">PG</span><span class="p">()</span> <span class="n">request</span><span class="o">.</span><span class="n">addfinalizer</span><span class="p">(</span><span class="n">db</span><span class="o">.</span><span class="n">destroy</span><span class="p">)</span> <span class="c"># destroy when session is finished</span> <span class="k">return</span> <span class="n">db</span> </pre></div> </div> <p>This would execute all tests requiring the per-session “db” resource twice, receiving the values created by the two respective invocations to the factory function.</p> </div> <div class="section" id="no-pytest-funcarg-prefix-when-using-fixture-decorator"> <h2>No <tt class="docutils literal"><span class="pre">pytest_funcarg__</span></tt> prefix when using @fixture decorator<a class="headerlink" href="#no-pytest-funcarg-prefix-when-using-fixture-decorator" title="Permalink to this headline">¶</a></h2> <p>When using the <tt class="docutils literal"><span class="pre">@fixture</span></tt> decorator the name of the function denotes the name under which the resource can be accessed as a function argument:</p> <div class="highlight-python"><div class="highlight"><pre><span class="nd">@pytest.fixture</span><span class="p">()</span> <span class="k">def</span> <span class="nf">db</span><span class="p">(</span><span class="n">request</span><span class="p">):</span> <span class="o">...</span> </pre></div> </div> <p>The name under which the funcarg resource can be requested is <tt class="docutils literal"><span class="pre">db</span></tt>.</p> <p>You can still use the “old” non-decorator way of specifying funcarg factories aka:</p> <div class="highlight-python"><div class="highlight"><pre><span class="k">def</span> <span class="nf">pytest_funcarg__db</span><span class="p">(</span><span class="n">request</span><span class="p">):</span> <span class="o">...</span> </pre></div> </div> <p>But it is then not possible to define scoping and parametrization. It is thus recommended to use the factory decorator.</p> </div> <div class="section" id="solving-per-session-setup-autouse-fixtures"> <h2>solving per-session setup / autouse fixtures<a class="headerlink" href="#solving-per-session-setup-autouse-fixtures" title="Permalink to this headline">¶</a></h2> <p>pytest for a long time offered a pytest_configure and a pytest_sessionstart hook which are often used to setup global resources. This suffers from several problems:</p> <ol class="arabic simple"> <li>in distributed testing the master process would setup test resources that are never needed because it only co-ordinates the test run activities of the slave processes.</li> <li>if you only perform a collection (with “–collectonly”) resource-setup will still be executed.</li> <li>If a pytest_sessionstart is contained in some subdirectories conftest.py file, it will not be called. This stems from the fact that this hook is actually used for reporting, in particular the test-header with platform/custom information.</li> </ol> <p>Moreover, it was not easy to define a scoped setup from plugins or conftest files other than to implement a <tt class="docutils literal"><span class="pre">pytest_runtest_setup()</span></tt> hook and caring for scoping/caching yourself. And it’s virtually impossible to do this with parametrization as <tt class="docutils literal"><span class="pre">pytest_runtest_setup()</span></tt> is called during test execution and parametrization happens at collection time.</p> <p>It follows that pytest_configure/session/runtest_setup are often not appropriate for implementing common fixture needs. Therefore, pytest-2.3 introduces <a class="reference internal" href="fixture.html#autouse-fixtures"><em>autouse fixtures (xUnit setup on steroids)</em></a> which fully integrate with the generic <a class="reference internal" href="fixture.html#fixture"><em>fixture mechanism</em></a> and obsolete many prior uses of pytest hooks.</p> </div> <div class="section" id="funcargs-fixture-discovery-now-happens-at-collection-time"> <h2>funcargs/fixture discovery now happens at collection time<a class="headerlink" href="#funcargs-fixture-discovery-now-happens-at-collection-time" title="Permalink to this headline">¶</a></h2> <p>pytest-2.3 takes care to discover fixture/funcarg factories at collection time. This is more efficient especially for large test suites. Moreover, a call to “py.test –collectonly” should be able to in the future show a lot of setup-information and thus presents a nice method to get an overview of fixture management in your project.</p> </div> <div class="section" id="conclusion-and-compatibility-notes"> <span id="funcargscompat"></span><span id="compatibility-notes"></span><h2>Conclusion and compatibility notes<a class="headerlink" href="#conclusion-and-compatibility-notes" title="Permalink to this headline">¶</a></h2> <p><strong>funcargs</strong> were originally introduced to pytest-2.0. In pytest-2.3 the mechanism was extended and refined and is now described as fixtures:</p> <ul class="simple"> <li>previously funcarg factories were specified with a special <tt class="docutils literal"><span class="pre">pytest_funcarg__NAME</span></tt> prefix instead of using the <tt class="docutils literal"><span class="pre">@pytest.fixture</span></tt> decorator.</li> <li>Factories received a <tt class="docutils literal"><span class="pre">request</span></tt> object which managed caching through <tt class="docutils literal"><span class="pre">request.cached_setup()</span></tt> calls and allowed using other funcargs via <tt class="docutils literal"><span class="pre">request.getfuncargvalue()</span></tt> calls. These intricate APIs made it hard to do proper parametrization and implement resource caching. The new <tt class="xref py py-func docutils literal"><span class="pre">pytest.fixture`()</span></tt> decorator allows to declare the scope and let pytest figure things out for you.</li> <li>if you used parametrization and funcarg factories which made use of <tt class="docutils literal"><span class="pre">request.cached_setup()</span></tt> it is recommeneded to invest a few minutes and simplify your fixture function code to use the <a class="reference internal" href="fixture.html#pytest-fixture"><em>Fixtures as Function arguments (funcargs)</em></a> decorator instead. This will also allow to take advantage of the automatic per-resource grouping of tests.</li> </ul> </div> </div> </div> </div> </div> <div class="clearer"></div> </div> <div class="related"> <h3>Navigation</h3> <ul> <li class="right" style="margin-right: 10px"> <a href="announce/index.html" title="Release announcements" >next</a></li> <li class="right" > <a href="contact.html" title="Contact channels" >previous</a> |</li> <li><a href="contents.html">pytest-2.3.4.1</a> »</li> <g:plusone></g:plusone> </ul> </div> <div class="footer"> © Copyright 2012, holger krekel. Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3. </div> <script type="text/javascript"> var _gaq = _gaq || []; _gaq.push(['_setAccount', 'UA-7597274-13']); _gaq.push(['_trackPageview']); (function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); })(); </script> <script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script> </body> </html>