Update getting-started.rst
This commit is contained in:
		
							parent
							
								
									3181718fe0
								
							
						
					
					
						commit
						1f4831a23f
					
				|  | @ -7,32 +7,34 @@ Installation and Getting Started | ||||||
| 
 | 
 | ||||||
| **PyPI package name**: `pytest <http://pypi.python.org/pypi/pytest>`_ | **PyPI package name**: `pytest <http://pypi.python.org/pypi/pytest>`_ | ||||||
| 
 | 
 | ||||||
| **dependencies**: `py <http://pypi.python.org/pypi/py>`_, | **Dependencies**: `py <http://pypi.python.org/pypi/py>`_, | ||||||
| `colorama (Windows) <http://pypi.python.org/pypi/colorama>`_, | `colorama (Windows) <http://pypi.python.org/pypi/colorama>`_, | ||||||
| 
 | 
 | ||||||
| **documentation as PDF**: `download latest <https://media.readthedocs.org/pdf/pytest/latest/pytest.pdf>`_ | **Documentation as PDF**: `download latest <https://media.readthedocs.org/pdf/pytest/latest/pytest.pdf>`_ | ||||||
|  | 
 | ||||||
|  | ``pytest`` is a framework that makes building simple and scalable tests easy. Tests are expressive and readable—no boilerplate code required. Get started in minutes with a small unit test or complex functional test for your application or library. | ||||||
| 
 | 
 | ||||||
| .. _`getstarted`: | .. _`getstarted`: | ||||||
| .. _installation: | .. _`installpytest`: | ||||||
| 
 | 
 | ||||||
| Installation | Install ``pytest`` | ||||||
| ---------------------------------------- | ---------------------------------------- | ||||||
| 
 | 
 | ||||||
| Installation:: | 1. Run the following command in your command line:: | ||||||
| 
 | 
 | ||||||
|     pip install -U pytest |     pip install -U pytest | ||||||
| 
 | 
 | ||||||
| To check your installation has installed the correct version:: | 2. Check that you installed the correct version:: | ||||||
| 
 | 
 | ||||||
|     $ pytest --version |     $ pytest --version | ||||||
|     This is pytest version 3.x.y, imported from $PYTHON_PREFIX/lib/python3.5/site-packages/pytest.py |     This is pytest version 3.x.y, imported from $PYTHON_PREFIX/lib/python3.5/site-packages/pytest.py | ||||||
| 
 | 
 | ||||||
| .. _`simpletest`: | .. _`createyourfirsttest`: | ||||||
| 
 | 
 | ||||||
| Our first test run | Create your first test | ||||||
| ---------------------------------------------------------- | ---------------------------------------------------------- | ||||||
| 
 | 
 | ||||||
| Let's create a first test file with a simple test function:: | Create a simple test function with just four lines of code:: | ||||||
| 
 | 
 | ||||||
|     # content of test_sample.py |     # content of test_sample.py | ||||||
|     def func(x): |     def func(x): | ||||||
|  | @ -41,7 +43,7 @@ Let's create a first test file with a simple test function:: | ||||||
|     def test_answer(): |     def test_answer(): | ||||||
|         assert func(3) == 5 |         assert func(3) == 5 | ||||||
| 
 | 
 | ||||||
| That's it. You can execute the test function now:: | That’s it. You can now execute the test function:: | ||||||
| 
 | 
 | ||||||
|     $ pytest |     $ pytest | ||||||
|     =========================== test session starts ============================ |     =========================== test session starts ============================ | ||||||
|  | @ -62,30 +64,26 @@ That's it. You can execute the test function now:: | ||||||
|     test_sample.py:5: AssertionError |     test_sample.py:5: AssertionError | ||||||
|     ========================= 1 failed in 0.12 seconds ========================= |     ========================= 1 failed in 0.12 seconds ========================= | ||||||
| 
 | 
 | ||||||
| We got a failure report because our little ``func(3)`` call did not return ``5``. | This test returns a failure report because ``func(3)`` does not return ``5``. | ||||||
| 
 | 
 | ||||||
| .. note:: | .. note:: | ||||||
| 
 | 
 | ||||||
|     You can simply use the ``assert`` statement for asserting test |     You can use the ``assert`` statement to verify test expectations. pytest’s :ref:`Advanced assertion introspection` will intelligently report intermediate values of the assert expression so you can avoid the many names `of JUnit legacy methods`_. | ||||||
|     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`_. |  | ||||||
| 
 | 
 | ||||||
| .. _`JUnit legacy methods`: http://docs.python.org/library/unittest.html#test-cases | .. _`JUnit legacy methods`: http://docs.python.org/library/unittest.html#test-cases | ||||||
| 
 | 
 | ||||||
| .. _`assert statement`: http://docs.python.org/reference/simple_stmts.html#the-assert-statement | .. _`Advanced assertion introspection`: http://docs.python.org/reference/simple_stmts.html#the-assert-statement | ||||||
| 
 | 
 | ||||||
| Running multiple tests | Run multiple tests | ||||||
| ---------------------------------------------------------- | ---------------------------------------------------------- | ||||||
| 
 | 
 | ||||||
| ``pytest`` will run all files in the current directory and its subdirectories of the form test_*.py or \*_test.py. More generally, it follows :ref:`standard test discovery rules <test discovery>`. | ``pytest`` will run all files of the form test_*.py or \*_test.py in the current directory and its subdirectories. More generally, it follows :ref:`standard test discovery rules <test discovery>`. | ||||||
| 
 | 
 | ||||||
| 
 | 
 | ||||||
| Asserting that a certain exception is raised | Assert that a certain exception is raised | ||||||
| -------------------------------------------------------------- | -------------------------------------------------------------- | ||||||
| 
 | 
 | ||||||
| If you want to assert that some code raises an exception you can | Use the ``raises`` helper to assert that some code raises an exception:: | ||||||
| use the ``raises`` helper:: |  | ||||||
| 
 | 
 | ||||||
|     # content of test_sysexit.py |     # content of test_sysexit.py | ||||||
|     import pytest |     import pytest | ||||||
|  | @ -96,18 +94,16 @@ use the ``raises`` helper:: | ||||||
|         with pytest.raises(SystemExit): |         with pytest.raises(SystemExit): | ||||||
|             f() |             f() | ||||||
| 
 | 
 | ||||||
| Running it with, this time in "quiet" reporting mode:: | Execute the test function with “quiet” reporting mode:: | ||||||
| 
 | 
 | ||||||
|     $ pytest -q test_sysexit.py |     $ pytest -q test_sysexit.py | ||||||
|     .                                                                    [100%] |     .                                                                    [100%] | ||||||
|     1 passed in 0.12 seconds |     1 passed in 0.12 seconds | ||||||
| 
 | 
 | ||||||
| Grouping multiple tests in a class | Group multiple tests in a class | ||||||
| -------------------------------------------------------------- | -------------------------------------------------------------- | ||||||
| 
 | 
 | ||||||
| Once you start to have more than a few tests it often makes sense | Once you develop multiple tests, you may want to group them into a class. pytest makes it easy to create a class containing more than one test:: | ||||||
| to group tests logically, in classes and modules.  Let's write a class |  | ||||||
| containing two tests:: |  | ||||||
| 
 | 
 | ||||||
|     # content of test_class.py |     # content of test_class.py | ||||||
|     class TestClass(object): |     class TestClass(object): | ||||||
|  | @ -119,9 +115,7 @@ containing two tests:: | ||||||
|             x = "hello" |             x = "hello" | ||||||
|             assert hasattr(x, 'check') |             assert hasattr(x, 'check') | ||||||
| 
 | 
 | ||||||
| The two tests are found because of the standard :ref:`test discovery`. | ``pytest`` discovers all tests following its :ref:`Conventions for Python test discovery <test discovery>`, so it finds both ``test_`` prefixed functions. There is no need to subclass anything. We can simply run the module by passing its filename: | ||||||
| There is no need to subclass anything.  We can simply |  | ||||||
| run the module by passing its filename:: |  | ||||||
| 
 | 
 | ||||||
|     $ pytest -q test_class.py |     $ pytest -q test_class.py | ||||||
|     .F                                                                   [100%] |     .F                                                                   [100%] | ||||||
|  | @ -139,26 +133,19 @@ run the module by passing its filename:: | ||||||
|     test_class.py:8: AssertionError |     test_class.py:8: AssertionError | ||||||
|     1 failed, 1 passed in 0.12 seconds |     1 failed, 1 passed in 0.12 seconds | ||||||
| 
 | 
 | ||||||
| The first test passed, the second failed. Again we can easily see | The first test passed and the second failed. You can easily see the intermediate values in the assertion to help you understand the reason for the failure. | ||||||
| the intermediate values used in the assertion, helping us to |  | ||||||
| understand the reason for the failure. |  | ||||||
| 
 | 
 | ||||||
| Going functional: requesting a unique temporary directory | Request a unique temporary directory for functional tests | ||||||
| -------------------------------------------------------------- | -------------------------------------------------------------- | ||||||
| 
 | 
 | ||||||
| For functional tests one often needs to create some files | ``pytest`` provides `Builtin fixtures/function arguments <https://docs.pytest.org/en/latest/builtin.html#builtinfixtures>`_ to request arbitrary resources, like a unique temporary directory: | ||||||
| and pass them to application objects.  pytest provides |  | ||||||
| :ref:`builtinfixtures` which allow to request arbitrary |  | ||||||
| resources, for example a unique temporary directory:: |  | ||||||
| 
 | 
 | ||||||
|     # content of test_tmpdir.py |     # content of test_tmpdir.py | ||||||
|     def test_needsfiles(tmpdir): |     def test_needsfiles(tmpdir): | ||||||
|         print (tmpdir) |         print (tmpdir) | ||||||
|         assert 0 |         assert 0 | ||||||
| 
 | 
 | ||||||
| We list the name ``tmpdir`` in the test function signature and | List the name ``tmpdir`` in the test function signature and ``pytest`` will lookup and call a fixture factory to create the resource before performing the test function call. Before the test runs, ``pytest`` creates a unique-per-test-invocation temporary directory:: | ||||||
| ``pytest`` will lookup and call a fixture factory to create the resource |  | ||||||
| before performing the test function call.  Let's just run it:: |  | ||||||
| 
 | 
 | ||||||
|     $ pytest -q test_tmpdir.py |     $ pytest -q test_tmpdir.py | ||||||
|     F                                                                    [100%] |     F                                                                    [100%] | ||||||
|  | @ -177,22 +164,21 @@ before performing the test function call.  Let's just run it:: | ||||||
|     PYTEST_TMPDIR/test_needsfiles0 |     PYTEST_TMPDIR/test_needsfiles0 | ||||||
|     1 failed in 0.12 seconds |     1 failed in 0.12 seconds | ||||||
| 
 | 
 | ||||||
| Before the test runs, a unique-per-test-invocation temporary directory | More info on tmpdir handeling is available at `Temporary directories and files <tmpdir handling>`_. | ||||||
| was created.  More info at :ref:`tmpdir handling`. |  | ||||||
| 
 | 
 | ||||||
| You can find out what kind of builtin :ref:`fixtures` exist by typing:: | Find out what kind of builtin ```pytest`` fixtures <fixtures>`_ exist with the command:: | ||||||
| 
 | 
 | ||||||
|     pytest --fixtures   # shows builtin and custom fixtures |     pytest --fixtures   # shows builtin and custom fixtures | ||||||
| 
 | 
 | ||||||
| Where to go next | Continue reading | ||||||
| ------------------------------------- | ------------------------------------- | ||||||
| 
 | 
 | ||||||
| Here are a few suggestions where to go next: | Check out additional pytest resources to help you customize tests for your unique workflow: | ||||||
| 
 | 
 | ||||||
| * :ref:`cmdline` for command line invocation examples | * ":ref:`cmdline`" for command line invocation examples | ||||||
| * :ref:`good practices <goodpractices>` for virtualenv, test layout | * ":ref:`goodpractices`" for virtualenv and test layouts | ||||||
| * :ref:`existingtestsuite` for working with pre-existing tests | * ":ref:`existingtestsuite`" for working with pre-existing tests | ||||||
| * :ref:`fixtures` for providing a functional baseline to your tests | * ":ref:`fixtures`" for providing a functional baseline to your tests | ||||||
| * :ref:`plugins` managing and writing plugins | * ":ref:`plugins`" for managing and writing plugins | ||||||
| 
 | 
 | ||||||
| .. include:: links.inc | .. include:: links.inc | ||||||
|  |  | ||||||
		Loading…
	
		Reference in New Issue