| Current File : //usr/share/doc/python-py-1.4.32/html/faq.html |
<!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>Frequently Asked Questions — py 1.4.32 documentation</title>
<link rel="stylesheet" href="_static/default.css" type="text/css" />
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: '',
VERSION: '1.4.32',
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="py 1.4.32 documentation" href="index.html" />
</head>
<body>
<div class="related">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
accesskey="I">index</a></li>
<li><a href="index.html">py 1.4.32 documentation</a> »</li>
</ul>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body">
<div class="section" id="frequently-asked-questions">
<h1>Frequently Asked Questions<a class="headerlink" href="#frequently-asked-questions" title="Permalink to this headline">¶</a></h1>
<div class="contents local topic" id="contents">
<ul class="simple">
<li><a class="reference internal" href="#on-naming-nosetests-licensing-and-magic" id="id1">On naming, nosetests, licensing and magic</a><ul>
<li><a class="reference internal" href="#why-the-py-naming-why-not-pytest" id="id2">Why the <tt class="docutils literal"><span class="pre">py</span></tt> naming? Why not <tt class="docutils literal"><span class="pre">pytest</span></tt>?</a></li>
<li><a class="reference internal" href="#why-the-py-test-naming" id="id3">Why the <tt class="docutils literal"><span class="pre">py.test</span></tt> naming?</a></li>
<li><a class="reference internal" href="#what-s-py-test-s-relation-to-nosetests" id="id4">What’s py.test’s relation to <tt class="docutils literal"><span class="pre">nosetests</span></tt>?</a></li>
<li><a class="reference internal" href="#what-s-this-magic-with-py-test" id="id5">What’s this “magic” with py.test?</a></li>
<li><a class="reference internal" href="#where-does-my-py-test-come-import-from" id="id6">Where does my <tt class="docutils literal"><span class="pre">py.test</span></tt> come/import from?</a></li>
</ul>
</li>
<li><a class="reference internal" href="#function-arguments-parametrized-tests-and-setup" id="id7">function arguments, parametrized tests and setup</a><ul>
<li><a class="reference internal" href="#is-using-funcarg-versus-xunit-based-setup-a-style-question" id="id8">Is using funcarg- versus xUnit-based setup a style question?</a></li>
<li><a class="reference internal" href="#why-the-pytest-funcarg-name-for-funcarg-factories" id="id9">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-factory-function" id="id10">Can I yield multiple values from a factory function?</a></li>
</ul>
</li>
<li><a class="reference internal" href="#py-test-interaction-with-other-packages" id="id11">py.test interaction with other packages</a><ul>
<li><a class="reference internal" href="#issues-with-py-test-multiprocess-and-setuptools" id="id12">Issues with py.test, multiprocess and setuptools?</a></li>
</ul>
</li>
</ul>
</div>
<div class="section" id="on-naming-nosetests-licensing-and-magic">
<h2><a class="toc-backref" href="#id1">On naming, nosetests, licensing and magic</a><a class="headerlink" href="#on-naming-nosetests-licensing-and-magic" title="Permalink to this headline">¶</a></h2>
<div class="section" id="why-the-py-naming-why-not-pytest">
<h3><a class="toc-backref" href="#id2">Why the <tt class="docutils literal"><span class="pre">py</span></tt> naming? Why not <tt class="docutils literal"><span class="pre">pytest</span></tt>?</a><a class="headerlink" href="#why-the-py-naming-why-not-pytest" title="Permalink to this headline">¶</a></h3>
<p>This mostly has historic reasons - the aim is
to get away from the somewhat questionable ‘py’ name
at some point. These days (2010) the ‘py’ library
almost completely comprises APIs that are used
by the <tt class="docutils literal"><span class="pre">py.test</span></tt> tool. There also are some
other uses, e.g. of the <tt class="docutils literal"><span class="pre">py.path.local()</span></tt> and
other path implementations. So it requires some
work to factor them out and do the shift.</p>
</div>
<div class="section" id="why-the-py-test-naming">
<h3><a class="toc-backref" href="#id3">Why the <tt class="docutils literal"><span class="pre">py.test</span></tt> naming?</a><a class="headerlink" href="#why-the-py-test-naming" title="Permalink to this headline">¶</a></h3>
<p>because of TAB-completion under Bash/Shells. If you hit
<tt class="docutils literal"><span class="pre">py.<TAB></span></tt> you’ll get a list of available development
tools that all share the <tt class="docutils literal"><span class="pre">py.</span></tt> prefix. Another motivation
was to unify the package (“py.test”) and tool filename.</p>
</div>
<div class="section" id="what-s-py-test-s-relation-to-nosetests">
<h3><a class="toc-backref" href="#id4">What’s py.test’s relation to <tt class="docutils literal"><span class="pre">nosetests</span></tt>?</a><a class="headerlink" href="#what-s-py-test-s-relation-to-nosetests" title="Permalink to this headline">¶</a></h3>
<p>py.test and <a class="reference external" href="http://somethingaboutorange.com/mrl/projects/nose/0.11.1/">nose</a> share basic philosophy when it comes
to running Python tests. In fact,
with py.test-1.1.0 it is ever easier to run many test suites
that currently work with <tt class="docutils literal"><span class="pre">nosetests</span></tt>. <a class="reference external" href="http://somethingaboutorange.com/mrl/projects/nose/0.11.1/">nose</a> was 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 so some of the newer <a class="reference external" href="test/features.html">features</a> introduced with py.test-1.0
and py.test-1.1 have no counterpart in <a class="reference external" href="http://somethingaboutorange.com/mrl/projects/nose/0.11.1/">nose</a>.</p>
</div>
<div class="section" id="what-s-this-magic-with-py-test">
<h3><a class="toc-backref" href="#id5">What’s this “magic” with py.test?</a><a class="headerlink" href="#what-s-this-magic-with-py-test" title="Permalink to this headline">¶</a></h3>
<p>issues where people have used the term “magic” in the past:</p>
<ul class="simple">
<li><a class="reference external" href="http://bitbucket.org/hpk42/py-trunk/src/trunk/py/__init__.py">py/__init__.py</a> uses the <a class="reference external" href="http://pypi.python.org/pypi/apipkg">apipkg</a> mechanism for lazy-importing
and full control on what API you get when importing “import py”.</li>
<li>when an <tt class="docutils literal"><span class="pre">assert</span></tt> statement fails, py.test re-interprets the expression
to show intermediate values if a test fails. If your expression
has side effects the intermediate values may not be the same, obfuscating
the initial error (this is also explained at the command line if it happens).
<tt class="docutils literal"><span class="pre">py.test</span> <span class="pre">--no-assert</span></tt> turns off assert re-intepretation.
Sidenote: it is good practise to avoid asserts with side effects.</li>
</ul>
</div>
<div class="section" id="where-does-my-py-test-come-import-from">
<h3><a class="toc-backref" href="#id6">Where does my <tt class="docutils literal"><span class="pre">py.test</span></tt> come/import from?</a><a class="headerlink" href="#where-does-my-py-test-come-import-from" title="Permalink to this headline">¶</a></h3>
<p>You can issue:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">py</span><span class="o">.</span><span class="n">test</span> <span class="o">--</span><span class="n">version</span>
</pre></div>
</div>
<p>which tells you both version and import location of the tool.</p>
</div>
</div>
<div class="section" id="function-arguments-parametrized-tests-and-setup">
<h2><a class="toc-backref" href="#id7">function arguments, parametrized tests and setup</a><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-based-setup-a-style-question">
<h3><a class="toc-backref" href="#id8">Is using funcarg- versus xUnit-based setup a style question?</a><a class="headerlink" href="#is-using-funcarg-versus-xunit-based-setup-a-style-question" title="Permalink to this headline">¶</a></h3>
<p>It depends. For simple applications or for people experienced
with <a class="reference external" href="http://somethingaboutorange.com/mrl/projects/nose/0.11.1/">nose</a> or unittest-style test setup using <a class="reference external" href="test/xunit_setup.html">xUnit style setup</a>
make some sense. For larger test suites, parametrized testing
or setup of complex test resources using <a class="reference external" href="test/funcargs.html">funcargs</a> is recommended.
Moreover, funcargs are ideal for writing advanced test support
code (like e.g. the <a class="reference external" href="test/plugin/monkeypatch.html">monkeypatch</a>, the <a class="reference external" href="test/plugin/tmpdir.html">tmpdir</a> or <a class="reference external" href="test/plugin/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><a class="toc-backref" href="#id9">Why the <tt class="docutils literal"><span class="pre">pytest_funcarg__*</span></tt> name for funcarg factories?</a><a class="headerlink" href="#why-the-pytest-funcarg-name-for-funcarg-factories" title="Permalink to this headline">¶</a></h3>
<p>When experimenting with funcargs an explicit registration mechanism
was considered. But lacking a good use case for this indirection and
flexibility we decided to go for <a class="reference external" href="http://en.wikipedia.org/wiki/Convention_over_Configuration">Convention over Configuration</a> and
allow to directly specify the factory. Besides removing the need
for an indirection it allows to “grep” for <tt class="docutils literal"><span class="pre">pytest_funcarg__MYARG</span></tt>
and will safely find all factory functions for the <tt class="docutils literal"><span class="pre">MYARG</span></tt> function
argument. It helps to alleviate the de-coupling of function
argument usage and creation.</p>
</div>
<div class="section" id="can-i-yield-multiple-values-from-a-factory-function">
<h3><a class="toc-backref" href="#id10">Can I yield multiple values from a factory function?</a><a class="headerlink" href="#can-i-yield-multiple-values-from-a-factory-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>Use the <a class="reference external" href="test/funcargs.html#parametrizing-tests">pytest_generate_tests</a> hook to solve both issues
and 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><a class="toc-backref" href="#id11">py.test interaction with other packages</a><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><a class="toc-backref" href="#id12">Issues with py.test, multiprocess and setuptools?</a><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 implicitely re-import a lot of local modules.
Unfortuantely, 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.
There are these workarounds:</p>
<ul class="simple">
<li><a class="reference external" href="http://pypi.python.org/pypi/distribute#installation-instructions">install Distribute</a> as a drop-in replacement for setuptools
and install py.test</li>
<li><a class="reference external" href="install.html#directly-use-a-checkout">directly use a checkout</a> which avoids all setuptools/Distribute
installation</li>
</ul>
<p>If those options are not available to you, you may also manually
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">py</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">py</span><span class="o">.</span><span class="n">cmdline</span><span class="o">.</span><span class="n">pytest</span><span class="p">()</span>
</pre></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="sphinxsidebar">
<div class="sphinxsidebarwrapper">
<h3><a href="index.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Frequently Asked 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="#why-the-py-naming-why-not-pytest">Why the <tt class="docutils literal"><span class="pre">py</span></tt> naming? Why not <tt class="docutils literal"><span class="pre">pytest</span></tt>?</a></li>
<li><a class="reference internal" href="#why-the-py-test-naming">Why the <tt class="docutils literal"><span class="pre">py.test</span></tt> naming?</a></li>
<li><a class="reference internal" href="#what-s-py-test-s-relation-to-nosetests">What’s py.test’s relation to <tt class="docutils literal"><span class="pre">nosetests</span></tt>?</a></li>
<li><a class="reference internal" href="#what-s-this-magic-with-py-test">What’s this “magic” with py.test?</a></li>
<li><a class="reference internal" href="#where-does-my-py-test-come-import-from">Where does my <tt class="docutils literal"><span class="pre">py.test</span></tt> come/import from?</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-based-setup-a-style-question">Is using funcarg- versus xUnit-based 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-factory-function">Can I yield multiple values from a factory 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>
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="_sources/faq.txt"
rel="nofollow">Show Source</a></li>
</ul>
<div id="searchbox" style="display: none">
<h3>Quick search</h3>
<form class="search" action="search.html" method="get">
<input type="text" name="q" />
<input type="submit" value="Go" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
<p class="searchtip" style="font-size: 90%">
Enter search terms or a module, class or function name.
</p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
>index</a></li>
<li><a href="index.html">py 1.4.32 documentation</a> »</li>
</ul>
</div>
<div class="footer">
© Copyright 2010, holger krekel et. al..
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-14']);
_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>
</body>
</html>