/usr/share/doc/python-pytest-doc/html/faq.html is in python-pytest-doc 2.6.3-2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 | <!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/flasky.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.6.2',
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="shortcut icon" href="_static/pytest1favi.ico"/>
<link rel="top" title="None" href="index.html" />
<link rel="up" title="Getting started basics" href="overview.html" />
<link rel="next" title="pytest reference documentation" href="apiref.html" />
<link rel="prev" title="Project examples" href="projects.html" />
<meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9">
</head>
<body>
<div class="related">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="apiref.html" title="pytest 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.6.2</a> »</li>
<li><a href="overview.html" accesskey="U">Getting started basics</a> »</li>
</ul>
</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">This FAQ is here only mostly for historic reasons. Checkout
<a class="reference external" href="http://stackoverflow.com/search?q=pytest">pytest Q&A at Stackoverflow</a>
for many questions and answers related to pytest and/or use
<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-pytest-relate-to-nose-and-unittest">
<h3>How does pytest relate to nose and unittest?<a class="headerlink" href="#how-does-pytest-relate-to-nose-and-unittest" title="Permalink to this headline">¶</a></h3>
<p><tt class="docutils literal"><span class="pre">pytest</span></tt> 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 <tt class="docutils literal"><span class="pre">pytest</span></tt>. <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">pytest</span></tt> when <tt class="docutils literal"><span class="pre">pytest</span></tt> 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-pytest-relate-to-twisted-s-trial">
<h3>how does pytest relate to twisted’s trial?<a class="headerlink" href="#how-does-pytest-relate-to-twisted-s-trial" title="Permalink to this headline">¶</a></h3>
<p>Since some time <tt class="docutils literal"><span class="pre">pytest</span></tt> 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-pytest-work-with-django">
<h3>how does pytest work with Django?<a class="headerlink" href="#how-does-pytest-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-pytest-historic-notes">
<h3>What’s this “magic” with pytest? (historic notes)<a class="headerlink" href="#what-s-this-magic-with-pytest-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 <tt class="docutils literal"><span class="pre">pytest</span></tt>
was using too much “magic”. It had been part of the <a class="reference external" href="http://py.readthedocs.org/en/latest/">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 release 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, <tt class="docutils literal"><span class="pre">pytest</span></tt> 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><tt class="docutils literal"><span class="pre">pytest</span></tt> 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, <tt class="docutils literal"><span class="pre">pytest</span></tt> 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">pytest</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="pytest-fixtures-parametrized-tests">
<h2>pytest fixtures, parametrized tests<a class="headerlink" href="#pytest-fixtures-parametrized-tests" title="Permalink to this headline">¶</a></h2>
<div class="section" id="is-using-pytest-fixtures-versus-xunit-setup-a-style-question">
<h3>Is using pytest fixtures versus xUnit setup a style question?<a class="headerlink" href="#is-using-pytest-fixtures-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="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>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>
<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>
</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</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="pytest-interaction-with-other-packages">
<h2>pytest interaction with other packages<a class="headerlink" href="#pytest-interaction-with-other-packages" title="Permalink to this headline">¶</a></h2>
<div class="section" id="issues-with-pytest-multiprocess-and-setuptools">
<h3>Issues with pytest, multiprocess and setuptools?<a class="headerlink" href="#issues-with-pytest-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>As of middle 2013, there shouldn’t be a problem anymore when you
use the standard setuptools (note that distribute has been merged
back into setuptools which is now shipped directly with virtualenv).</p>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="sphinxsidebar">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="contents.html">
<img class="logo" src="_static/pytest1.png" alt="Logo"/>
</a></p><h3><a href="contents.html">Table Of Contents</a></h3>
<ul>
<li><a href="index.html">Home</a></li>
<li><a href="contents.html">Contents</a></li>
<li><a href="getting-started.html">Install</a></li>
<li><a href="example/index.html">Examples</a></li>
<li><a href="customize.html">Customize</a></li>
<li><a href="contact.html">Contact</a></li>
<li><a href="talks.html">Talks/Posts</a></li>
<li><a href="changelog.html">Changelog</a></li>
</ul>
<hr>
<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-pytest-relate-to-nose-and-unittest">How does pytest relate to nose and unittest?</a></li>
<li><a class="reference internal" href="#how-does-pytest-relate-to-twisted-s-trial">how does pytest relate to twisted’s trial?</a></li>
<li><a class="reference internal" href="#how-does-pytest-work-with-django">how does pytest work with Django?</a></li>
<li><a class="reference internal" href="#what-s-this-magic-with-pytest-historic-notes">What’s this “magic” with pytest? (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="#pytest-fixtures-parametrized-tests">pytest fixtures, parametrized tests</a><ul>
<li><a class="reference internal" href="#is-using-pytest-fixtures-versus-xunit-setup-a-style-question">Is using pytest fixtures versus xUnit setup a style question?</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="#pytest-interaction-with-other-packages">pytest interaction with other packages</a><ul>
<li><a class="reference internal" href="#issues-with-pytest-multiprocess-and-setuptools">Issues with pytest, multiprocess and setuptools?</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h3>Related Topics</h3>
<ul>
<li><a href="contents.html">Documentation overview</a><ul>
<li><a href="overview.html">Getting started basics</a><ul>
<li>Previous: <a href="projects.html" title="previous chapter">Project examples</a></li>
<li>Next: <a href="apiref.html" title="next chapter">pytest reference documentation</a></li>
</ul></li>
</ul></li>
</ul><h3>Useful Links</h3>
<ul>
<li><a href="index.html">The pytest Website</a></li>
<li><a href="contributing.html">Contribution Guide</a></li>
<li><a href="https://pypi.python.org/pypi/pytest">pytest @ PyPI</a></li>
<li><a href="https://bitbucket.org/hpk42/pytest/">pytest @ Bitbucket</a></li>
<li><a href="http://pytest.org/latest/plugins_index/index.html">3rd party plugins</a></li>
<li><a href="https://bitbucket.org/hpk42/pytest/issues?status=new&status=open">Issue Tracker</a></li>
<li><a href="http://pytest.org/latest/pytest.pdf">PDF Documentation</a>
</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="footer">
© Copyright 2014, holger krekel.
Created using <a href="http://sphinx.pocoo.org/">Sphinx</a>.
</div>
</body>
</html>
|