<!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>Some Issues and Questions</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="up" title="Getting started basics" href="overview.html" />
<link rel="next" title="py.test reference documentation" href="apiref.html" />
<link rel="prev" title="Project examples" href="projects.html" />
</head>
<body>
<div class="related">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="apiref.html" title="py.test reference documentation"
accesskey="N">next</a></li>
<li class="right" >
<a href="projects.html" title="Project examples"
accesskey="P">previous</a> |</li>
<li><a href="contents.html">pytest-2.3.4.1</a> »</li>
<li><a href="overview.html" accesskey="U">Getting started basics</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="#">Some Issues and Questions</a><ul>
<li><a class="reference internal" href="#on-naming-nosetests-licensing-and-magic">On naming, nosetests, licensing and magic</a><ul>
<li><a class="reference internal" href="#how-does-py-test-relate-to-nose-and-unittest">How does py.test relate to nose and unittest?</a></li>
<li><a class="reference internal" href="#how-does-py-test-relate-to-twisted-s-trial">how does py.test relate to twisted’s trial?</a></li>
<li><a class="reference internal" href="#how-does-py-test-work-with-django">how does py.test work with Django?</a></li>
<li><a class="reference internal" href="#what-s-this-magic-with-py-test-historic-notes">What’s this “magic” with py.test? (historic notes)</a></li>
<li><a class="reference internal" href="#why-a-py-test-instead-of-a-pytest-command">Why a <tt class="docutils literal"><span class="pre">py.test</span></tt> instead of a <tt class="docutils literal"><span class="pre">pytest</span></tt> command?</a></li>
</ul>
</li>
<li><a class="reference internal" href="#function-arguments-parametrized-tests-and-setup">Function arguments, parametrized tests and setup</a><ul>
<li><a class="reference internal" href="#is-using-funcarg-versus-xunit-setup-a-style-question">Is using funcarg- versus xUnit setup a style question?</a></li>
<li><a class="reference internal" href="#why-the-pytest-funcarg-name-for-funcarg-factories">Why the <tt class="docutils literal"><span class="pre">pytest_funcarg__*</span></tt> name for funcarg factories?</a></li>
<li><a class="reference internal" href="#can-i-yield-multiple-values-from-a-fixture-function-function">Can I yield multiple values from a fixture function function?</a></li>
</ul>
</li>
<li><a class="reference internal" href="#py-test-interaction-with-other-packages">py.test interaction with other packages</a><ul>
<li><a class="reference internal" href="#issues-with-py-test-multiprocess-and-setuptools">Issues with py.test, multiprocess and setuptools?</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h4>Previous topic</h4>
<p class="topless"><a href="projects.html"
title="previous chapter">Project examples</a></p>
<h4>Next topic</h4>
<p class="topless"><a href="apiref.html"
title="next chapter">py.test reference documentation</a></p>
</div>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body">
<div class="section" id="some-issues-and-questions">
<h1>Some Issues and Questions<a class="headerlink" href="#some-issues-and-questions" title="Permalink to this headline">¶</a></h1>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">If you don’t find an answer here, you may checkout
<a class="reference external" href="http://stackoverflow.com/search?q=pytest">pytest Q&A at Stackoverflow</a>
or other <a class="reference internal" href="contact.html#contact-channels"><em>Contact channels</em></a> to get help.</p>
</div>
<div class="section" id="on-naming-nosetests-licensing-and-magic">
<h2>On naming, nosetests, licensing and magic<a class="headerlink" href="#on-naming-nosetests-licensing-and-magic" title="Permalink to this headline">¶</a></h2>
<div class="section" id="how-does-py-test-relate-to-nose-and-unittest">
<h3>How does py.test relate to nose and unittest?<a class="headerlink" href="#how-does-py-test-relate-to-nose-and-unittest" title="Permalink to this headline">¶</a></h3>
<p>py.test and <a class="reference external" href="http://somethingaboutorange.com/mrl/projects/nose/">nose</a> share basic philosophy when it comes
to running and writing Python tests. In fact, you can run many tests
written for nose with py.test. <a class="reference external" href="http://somethingaboutorange.com/mrl/projects/nose/">nose</a> was originally created
as a clone of <tt class="docutils literal"><span class="pre">py.test</span></tt> when py.test was in the <tt class="docutils literal"><span class="pre">0.8</span></tt> release
cycle. Note that starting with pytest-2.0 support for running unittest
test suites is majorly improved.</p>
</div>
<div class="section" id="how-does-py-test-relate-to-twisted-s-trial">
<h3>how does py.test relate to twisted’s trial?<a class="headerlink" href="#how-does-py-test-relate-to-twisted-s-trial" title="Permalink to this headline">¶</a></h3>
<p>Since some time py.test has builtin support for supporting tests
written using trial. It does not itself start a reactor, however,
and does not handle Deferreds returned from a test in pytest style.
If you are using trial’s unittest.TestCase chances are that you can
just run your tests even if you return Deferreds. In addition,
there also is a dedicated <a class="reference external" href="http://pypi.python.org/pypi/pytest-twisted">pytest-twisted</a> plugin which allows to
return deferreds from pytest-style tests, allowing to use
<a class="reference internal" href="fixture.html#fixtures"><em>pytest fixtures: explicit, modular, scalable</em></a> and other features.</p>
</div>
<div class="section" id="how-does-py-test-work-with-django">
<h3>how does py.test work with Django?<a class="headerlink" href="#how-does-py-test-work-with-django" title="Permalink to this headline">¶</a></h3>
<p>In 2012, some work is going into the <a class="reference external" href="http://pypi.python.org/pypi/pytest-django">pytest-django plugin</a>. It substitutes the usage of Django’s
<tt class="docutils literal"><span class="pre">manage.py</span> <span class="pre">test</span></tt> and allows to use all pytest <a class="reference external" href="features.html">features</a> most of which
are not available from Django directly.</p>
</div>
<div class="section" id="what-s-this-magic-with-py-test-historic-notes">
<h3>What’s this “magic” with py.test? (historic notes)<a class="headerlink" href="#what-s-this-magic-with-py-test-historic-notes" title="Permalink to this headline">¶</a></h3>
<p>Around 2007 (version <tt class="docutils literal"><span class="pre">0.8</span></tt>) some people thought that py.test
was using too much “magic”. It had been part of the <a class="reference external" href="http://pylib.org">pylib</a> which
contains a lot of unreleated python library code. Around 2010 there
was a major cleanup refactoring, which removed unused or deprecated code
and resulted in the new <tt class="docutils literal"><span class="pre">pytest</span></tt> PyPI package which strictly contains
only test-related code. This relese also brought a complete pluginification
such that the core is around 300 lines of code and everything else is
implemented in plugins. Thus <tt class="docutils literal"><span class="pre">pytest</span></tt> today is a small, universally runnable
and customizable testing framework for Python. Note, however, that
<tt class="docutils literal"><span class="pre">pytest</span></tt> uses metaprogramming techniques and reading its source is
thus likely not something for Python beginners.</p>
<p>A second “magic” issue was the assert statement debugging feature.
Nowadays, py.test explicitely rewrites assert statements in test modules
in order to provide more useful <a class="reference internal" href="assert.html#assertfeedback"><em>assert feedback</em></a>.
This completely avoids previous issues of confusing assertion-reporting.
It also means, that you can use Python’s <tt class="docutils literal"><span class="pre">-O</span></tt> optimization without loosing
assertions in test modules.</p>
<p>py.test contains a second mostly obsolete assert debugging technique,
invoked via <tt class="docutils literal"><span class="pre">--assert=reinterpret</span></tt>, activated by default on
Python-2.5: When an <tt class="docutils literal"><span class="pre">assert</span></tt> statement fails, py.test re-interprets
the expression part to show intermediate values. This technique suffers
from a caveat that the rewriting does not: If your expression has side
effects (better to avoid them anyway!) the intermediate values may not
be the same, confusing the reinterpreter and obfuscating the initial
error (this is also explained at the command line if it happens).</p>
<p>You can also turn off all assertion interaction using the
<tt class="docutils literal"><span class="pre">--assertmode=off</span></tt> option.</p>
</div>
<div class="section" id="why-a-py-test-instead-of-a-pytest-command">
<h3>Why a <tt class="docutils literal"><span class="pre">py.test</span></tt> instead of a <tt class="docutils literal"><span class="pre">pytest</span></tt> command?<a class="headerlink" href="#why-a-py-test-instead-of-a-pytest-command" title="Permalink to this headline">¶</a></h3>
<p>Some of the reasons are historic, others are practical. <tt class="docutils literal"><span class="pre">py.test</span></tt>
used to be part of the <tt class="docutils literal"><span class="pre">py</span></tt> package which provided several developer
utilities, all starting with <tt class="docutils literal"><span class="pre">py.<TAB></span></tt>, thus providing nice
TAB-completion. If
you install <tt class="docutils literal"><span class="pre">pip</span> <span class="pre">install</span> <span class="pre">pycmd</span></tt> you get these tools from a separate
package. These days the command line tool could be called <tt class="docutils literal"><span class="pre">pytest</span></tt>
but since many people have gotten used to the old name and there
is another tool named “pytest” we just decided to stick with
<tt class="docutils literal"><span class="pre">py.test</span></tt> for now.</p>
</div>
</div>
<div class="section" id="function-arguments-parametrized-tests-and-setup">
<h2>Function arguments, parametrized tests and setup<a class="headerlink" href="#function-arguments-parametrized-tests-and-setup" title="Permalink to this headline">¶</a></h2>
<div class="section" id="is-using-funcarg-versus-xunit-setup-a-style-question">
<h3>Is using funcarg- versus xUnit setup a style question?<a class="headerlink" href="#is-using-funcarg-versus-xunit-setup-a-style-question" title="Permalink to this headline">¶</a></h3>
<p>For simple applications and for people experienced with <a class="reference external" href="http://somethingaboutorange.com/mrl/projects/nose/">nose</a> or
unittest-style test setup using <a class="reference external" href="xunit_setup.html">xUnit style setup</a> probably
feels natural. For larger test suites, parametrized testing
or setup of complex test resources using <a class="reference external" href="funcargs.html">funcargs</a> may feel more natural.
Moreover, funcargs are ideal for writing advanced test support
code (like e.g. the <a class="reference external" href="monkeypatch.html">monkeypatch</a>, the <a class="reference external" href="tmpdir.html">tmpdir</a> or <a class="reference external" href="capture.html">capture</a> funcargs)
because the support code can register setup/teardown functions
in a managed class/module/function scope.</p>
</div>
<div class="section" id="why-the-pytest-funcarg-name-for-funcarg-factories">
<span id="why-pytest-pyfuncarg-methods"></span><h3>Why the <tt class="docutils literal"><span class="pre">pytest_funcarg__*</span></tt> name for funcarg factories?<a class="headerlink" href="#why-the-pytest-funcarg-name-for-funcarg-factories" title="Permalink to this headline">¶</a></h3>
<p>We like <a class="reference external" href="http://en.wikipedia.org/wiki/Convention_over_Configuration">Convention over Configuration</a> and didn’t see much point
in allowing a more flexible or abstract mechanism. Moreover,
it is nice to be able to search for <tt class="docutils literal"><span class="pre">pytest_funcarg__MYARG</span></tt> in
source code and safely find all factory functions for
the <tt class="docutils literal"><span class="pre">MYARG</span></tt> function argument.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">With pytest-2.3 you can use the <a class="reference internal" href="fixture.html#pytest-fixture"><em>Fixtures as Function arguments (funcargs)</em></a> decorator
to mark a function as a fixture function.</p>
</div>
</div>
<div class="section" id="can-i-yield-multiple-values-from-a-fixture-function-function">
<h3>Can I yield multiple values from a fixture function function?<a class="headerlink" href="#can-i-yield-multiple-values-from-a-fixture-function-function" title="Permalink to this headline">¶</a></h3>
<p>There are two conceptual reasons why yielding from a factory function
is not possible:</p>
<ul class="simple">
<li>Calling factories for obtaining test function arguments
is part of setting up and running a test. At that
point it is not possible to add new test calls to
the test collection anymore.</li>
<li>If multiple factories yielded values there would
be no natural place to determine the combination
policy - in real-world examples some combinations
often should not run.</li>
</ul>
<p>However, with pytest-2.3 you can use the <a class="reference internal" href="fixture.html#pytest-fixture"><em>Fixtures as Function arguments (funcargs)</em></a> decorator
and specify <tt class="docutils literal"><span class="pre">params</span></tt> so that all tests depending on the factory-created
resource will run multiple times with different parameters.</p>
<p>You can also use the <a class="reference external" href="test/funcargs.html#parametrizing-tests">pytest_generate_tests</a> hook to
implement the <a class="reference external" href="http://tetamap.wordpress.com/2009/05/13/parametrizing-python-tests-generalized/">parametrization scheme of your choice</a>.</p>
</div>
</div>
<div class="section" id="py-test-interaction-with-other-packages">
<h2>py.test interaction with other packages<a class="headerlink" href="#py-test-interaction-with-other-packages" title="Permalink to this headline">¶</a></h2>
<div class="section" id="issues-with-py-test-multiprocess-and-setuptools">
<h3>Issues with py.test, multiprocess and setuptools?<a class="headerlink" href="#issues-with-py-test-multiprocess-and-setuptools" title="Permalink to this headline">¶</a></h3>
<p>On windows the multiprocess package will instantiate sub processes
by pickling and thus implicitly re-import a lot of local modules.
Unfortunately, setuptools-0.6.11 does not <tt class="docutils literal"><span class="pre">if</span> <span class="pre">__name__=='__main__'</span></tt>
protect its generated command line script. This leads to infinite
recursion when running a test that instantiates Processes.</p>
<p>A good solution is to <a class="reference external" href="http://pypi.python.org/pypi/distribute#installation-instructions">install Distribute</a> as a drop-in replacement
for setuptools and then re-install <tt class="docutils literal"><span class="pre">pytest</span></tt>. Otherwise you could
fix the script that is created by setuptools by inserting an
<tt class="docutils literal"><span class="pre">if</span> <span class="pre">__name__</span> <span class="pre">==</span> <span class="pre">'__main__'</span></tt>. Or you can create a “pytest.py”
script with this content and invoke that with the python version:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">import</span> <span class="nn">pytest</span>
<span class="k">if</span> <span class="n">__name__</span> <span class="o">==</span> <span class="s">'__main__'</span><span class="p">:</span>
<span class="n">pytest</span><span class="o">.</span><span class="n">main</span><span class="p">()</span>
</pre></div>
</div>
</div>
</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="apiref.html" title="py.test reference documentation"
>next</a></li>
<li class="right" >
<a href="projects.html" title="Project examples"
>previous</a> |</li>
<li><a href="contents.html">pytest-2.3.4.1</a> »</li>
<li><a href="overview.html" >Getting started basics</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>
