2010-11-02 07:53:53 +08:00
Installation and Getting Started
2010-10-14 07:25:09 +08:00
===================================
2010-10-14 01:30:00 +08:00
2015-09-17 19:30:35 +08:00
**Pythons** : Python 2.6,2.7,3.3,3.4,3.5, Jython, PyPy-2.3
2011-07-09 18:02:22 +08:00
**Platforms** : Unix/Posix and Windows
**PyPI package name** : `pytest <http://pypi.python.org/pypi/pytest> `_
2010-10-14 01:30:00 +08:00
2014-05-14 15:14:40 +08:00
**dependencies** : `py <http://pypi.python.org/pypi/py> `_ ,
`colorama (Windows) <http://pypi.python.org/pypi/colorama> `_ ,
`argparse (py26) <http://pypi.python.org/pypi/argparse> `_ .
2011-07-09 19:23:58 +08:00
**documentation as PDF** : `download latest <http://pytest.org/latest/pytest.pdf> `_
2010-11-25 19:11:10 +08:00
.. _`getstarted`:
2012-10-12 20:52:36 +08:00
.. _installation:
2010-11-25 19:11:10 +08:00
2010-10-25 03:55:27 +08:00
Installation
----------------------------------------
2010-10-14 01:30:00 +08:00
2010-10-25 03:55:27 +08:00
Installation options::
2010-10-14 07:25:09 +08:00
2011-09-23 13:35:47 +08:00
pip install -U pytest # or
easy_install -U pytest
2010-10-14 07:25:09 +08:00
2010-10-25 03:55:27 +08:00
To check your installation has installed the correct version::
2010-10-14 07:25:09 +08:00
$ py.test --version
2015-06-07 05:30:49 +08:00
This is pytest version 2.8.0.dev4, imported from $PWD/pytest.pyc
2010-10-14 07:25:09 +08:00
2010-11-06 06:37:25 +08:00
If you get an error checkout :ref: `installation issues` .
2010-10-14 01:30:00 +08:00
2010-11-25 19:11:10 +08:00
.. _`simpletest`:
2010-11-02 07:53:53 +08:00
Our first test run
2010-10-25 03:55:27 +08:00
----------------------------------------------------------
2010-10-14 01:30:00 +08:00
2010-11-06 06:37:25 +08:00
Let's create a first test file with a simple test function::
2010-10-14 01:30:00 +08:00
# content of test_sample.py
def func(x):
return x + 1
2010-11-06 06:37:25 +08:00
2010-10-14 01:30:00 +08:00
def test_answer():
assert func(3) == 5
2010-11-06 06:37:25 +08:00
That's it. You can execute the test function now::
2010-10-14 01:30:00 +08:00
2010-11-06 06:37:25 +08:00
$ py.test
2015-06-07 05:30:49 +08:00
======= test session starts ========
platform linux2 -- Python 2.7.9, pytest-2.8.0.dev4, py-1.4.28, pluggy-0.3.0
rootdir: $REGENDOC_TMPDIR, inifile:
2012-10-07 19:06:17 +08:00
collected 1 items
2014-09-05 19:55:00 +08:00
2010-10-14 01:30:00 +08:00
test_sample.py F
2014-09-05 19:55:00 +08:00
2015-06-07 05:30:49 +08:00
======= FAILURES ========
_______ test_answer ________
2014-09-05 19:55:00 +08:00
2010-10-14 01:30:00 +08:00
def test_answer():
> assert func(3) == 5
E assert 4 == 5
E + where 4 = func(3)
2014-09-05 19:55:00 +08:00
2010-11-06 06:37:25 +08:00
test_sample.py:5: AssertionError
2015-06-07 05:30:49 +08:00
======= 1 failed in 0.12 seconds ========
2010-10-14 01:30:00 +08:00
2014-01-18 19:31:33 +08:00
`` pytest `` found the `` test_answer `` function by following :ref: `standard test discovery rules <test discovery>` , basically detecting the `` test_ `` prefixes. We got a failure report because our little `` func(3) `` call did not return `` 5 `` .
2010-10-14 01:30:00 +08:00
2010-11-02 07:53:53 +08:00
.. note ::
2010-10-14 01:30:00 +08:00
2011-06-15 13:50:34 +08:00
You can simply use the `` assert `` statement for asserting test
expectations. pytest's :ref: `assert introspection` will intelligently
report intermediate values of the assert expression freeing
you from the need to learn the many names of `JUnit legacy methods`_ .
2010-11-02 07:53:53 +08:00
2011-07-07 03:47:33 +08:00
.. _`JUnit legacy methods`: http://docs.python.org/library/unittest.html#test-cases
2010-10-14 01:30:00 +08:00
.. _`assert statement`: http://docs.python.org/reference/simple_stmts.html#the-assert-statement
2011-03-04 06:40:38 +08:00
Asserting that a certain exception is raised
2010-10-25 03:55:27 +08:00
--------------------------------------------------------------
2011-03-04 06:40:38 +08:00
If you want to assert that some code raises an exception you can
2010-10-25 03:55:27 +08:00
use the `` raises `` helper::
# content of test_sysexit.py
2010-11-18 05:12:16 +08:00
import pytest
2010-10-25 03:55:27 +08:00
def f():
raise SystemExit(1)
def test_mytest():
2010-11-18 05:12:16 +08:00
with pytest.raises(SystemExit):
2010-10-25 03:55:27 +08:00
f()
2010-11-02 07:53:53 +08:00
Running it with, this time in "quiet" reporting mode::
$ py.test -q test_sysexit.py
.
2015-06-07 05:30:49 +08:00
1 passed in 0.12 seconds
2010-11-02 07:53:53 +08:00
2010-11-06 06:37:25 +08:00
.. todo :: For further ways to assert exceptions see the `raises`
2010-11-02 07:53:53 +08:00
Grouping multiple tests in a class
--------------------------------------------------------------
2011-03-04 06:40:38 +08:00
Once you start to have more than a few tests it often makes sense
to group tests logically, in classes and modules. Let's write a class
containing two tests::
2010-11-02 07:53:53 +08:00
# content of test_class.py
class TestClass:
def test_one(self):
x = "this"
assert 'h' in x
2010-10-25 03:55:27 +08:00
2010-11-02 07:53:53 +08:00
def test_two(self):
x = "hello"
assert hasattr(x, 'check')
2010-11-06 06:37:25 +08:00
The two tests are found because of the standard :ref: `test discovery` .
There is no need to subclass anything. We can simply
run the module by passing its filename::
2010-11-02 07:53:53 +08:00
$ py.test -q test_class.py
.F
2015-06-07 05:30:49 +08:00
======= FAILURES ========
_______ TestClass.test_two ________
2014-09-05 19:55:00 +08:00
2015-06-07 05:30:49 +08:00
self = <test_class.TestClass instance at 0xdeadbeef>
2014-09-05 19:55:00 +08:00
2010-11-02 07:53:53 +08:00
def test_two(self):
x = "hello"
> assert hasattr(x, 'check')
2011-08-21 00:37:00 +08:00
E assert hasattr('hello', 'check')
2014-09-05 19:55:00 +08:00
2010-11-02 07:53:53 +08:00
test_class.py:8: AssertionError
2015-06-07 05:30:49 +08:00
1 failed, 1 passed in 0.12 seconds
2010-10-14 07:25:09 +08:00
2010-11-06 06:37:25 +08:00
The first test passed, the second failed. Again we can easily see
the intermediate values used in the assertion, helping us to
understand the reason for the failure.
Going functional: requesting a unique temporary directory
--------------------------------------------------------------
For functional tests one often needs to create some files
2012-10-07 19:06:17 +08:00
and pass them to application objects. pytest provides
2014-01-18 19:31:33 +08:00
:ref: `builtinfixtures` which allow to request arbitrary
2012-10-07 19:06:17 +08:00
resources, for example a unique temporary directory::
2010-11-06 06:37:25 +08:00
# content of test_tmpdir.py
def test_needsfiles(tmpdir):
2014-09-02 18:20:16 +08:00
print (tmpdir)
2010-11-06 06:37:25 +08:00
assert 0
We list the name `` tmpdir `` in the test function signature and
2014-01-18 19:31:33 +08:00
`` pytest `` will lookup and call a fixture factory to create the resource
2010-11-06 06:37:25 +08:00
before performing the test function call. Let's just run it::
$ py.test -q test_tmpdir.py
2014-09-05 19:55:00 +08:00
F
2015-06-07 05:30:49 +08:00
======= FAILURES ========
_______ test_needsfiles ________
2014-09-05 19:55:00 +08:00
2015-06-07 05:30:49 +08:00
tmpdir = local('/tmp/pytest-NaN/test_needsfiles0')
2014-09-05 19:55:00 +08:00
def test_needsfiles(tmpdir):
print (tmpdir)
> assert 0
E assert 0
test_tmpdir.py:3: AssertionError
2015-06-07 05:30:49 +08:00
----------------------------- Captured stdout call -----------------------------
/tmp/pytest-NaN/test_needsfiles0
1 failed in 0.12 seconds
2010-11-06 06:37:25 +08:00
Before the test runs, a unique-per-test-invocation temporary directory
was created. More info at :ref: `tmpdir handling` .
2012-10-07 19:06:17 +08:00
You can find out what kind of builtin :ref: `fixtures` exist by typing::
2010-11-06 06:37:25 +08:00
2012-10-07 19:06:17 +08:00
py.test --fixtures # shows builtin and custom fixtures
2010-11-06 06:37:25 +08:00
2011-09-06 17:43:42 +08:00
Where to go next
2010-10-14 07:25:09 +08:00
-------------------------------------
Here are a few suggestions where to go next:
* :ref: `cmdline` for command line invocation examples
2011-03-04 06:40:38 +08:00
* :ref: `good practises <goodpractises>` for virtualenv, test layout, genscript support
2012-10-19 17:12:13 +08:00
* :ref: `fixtures` for providing a functional baseline to your tests
2014-01-18 19:31:33 +08:00
* :ref: `apiref` for documentation and examples on using `` pytest ``
2010-11-06 06:37:25 +08:00
* :ref: `plugins` managing and writing plugins
2010-11-02 07:53:53 +08:00
.. _`installation issues`:
2010-11-06 06:37:25 +08:00
Known Installation issues
2010-11-02 07:53:53 +08:00
------------------------------
easy_install or pip not found?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2011-09-23 13:35:47 +08:00
.. _`install pip`: http://www.pip-installer.org/en/latest/index.html
`Install pip`_ for a state of the art python package installer.
2013-08-01 15:42:44 +08:00
Install `setuptools`_ to get `` easy_install `` which allows to install
`` .egg `` binary format packages in addition to source-based ones.
2010-11-02 07:53:53 +08:00
py.test not found on Windows despite installation?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
.. _`Python for Windows`: http://www.imladris.com/Scripts/PythonForWindows.html
- **Windows** : If "easy_install" or "py.test" are not found
2010-11-18 21:56:16 +08:00
you need to add the Python script path to your `` PATH `` , see here:
`Python for Windows`_ . You may alternatively use an `ActivePython install`_
which does this for you automatically.
2010-11-02 07:53:53 +08:00
.. _`ActivePython install`: http://www.activestate.com/activepython/downloads
.. _`Jython does not create command line launchers`: http://bugs.jython.org/issue1491
- **Jython2.5.1 on Windows XP** : `Jython does not create command line launchers`_
so `` py.test `` will not work correctly. You may install py.test on
CPython and type `` py.test --genscript=mytest `` and then use
2014-01-18 19:31:33 +08:00
`` jython mytest `` to run your tests with Jython using `` pytest `` .
2010-11-02 07:53:53 +08:00
:ref: `examples` for more complex examples
2010-10-14 07:25:09 +08:00
2010-10-22 16:09:26 +08:00
.. include :: links.inc