<!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>
