From f2300fbab2525d3d95f125e14c0bbd9d08c58d77 Mon Sep 17 00:00:00 2001 From: Bruno Oliveira Date: Thu, 6 Apr 2017 23:29:41 -0300 Subject: [PATCH] Fix links in docs --- doc/en/existingtestsuite.rst | 26 ++++++++++++++------------ doc/en/getting-started.rst | 22 +++++++++++----------- 2 files changed, 25 insertions(+), 23 deletions(-) diff --git a/doc/en/existingtestsuite.rst b/doc/en/existingtestsuite.rst index a85aaaeb5..d304b30c9 100644 --- a/doc/en/existingtestsuite.rst +++ b/doc/en/existingtestsuite.rst @@ -1,32 +1,34 @@ +.. _existingtestsuite: + Using pytest with an existing test suite =========================================== -Pytest can be used with most existing test suites, but its -behavior differs from other test runners such as :ref:`nose` or -Python's default unittest framework. +Pytest can be used with most existing test suites, but its +behavior differs from other test runners such as :ref:`nose ` or +Python's default unittest framework. -Before using this section you will want to :ref:`getting-started `. +Before using this section you will want to :ref:`install pytest `. Running an existing test suite with pytest --------------------------------------------- -Say you want to contribute to an existing repository somewhere. -After pulling the code into your development space using some +Say you want to contribute to an existing repository somewhere. +After pulling the code into your development space using some flavor of version control and (optionally) setting up a virtualenv you will want to run:: - + cd - pip install -e . # Environment dependent alternatives include - # 'python setup.py develop' and 'conda develop' + pip install -e . # Environment dependent alternatives include + # 'python setup.py develop' and 'conda develop' in your project root. This will set up a symlink to your code in site-packages, allowing you to edit your code while your tests run against it as if it were installed. -Setting up your project in development mode lets you avoid having to -reinstall every time you want to run your tests, and is less brittle than +Setting up your project in development mode lets you avoid having to +reinstall every time you want to run your tests, and is less brittle than mucking about with sys.path to point your tests at local code. -Also consider using `Tox `_. +Also consider using :ref:`tox `. .. include:: links.inc diff --git a/doc/en/getting-started.rst b/doc/en/getting-started.rst index 071b296db..9f2aa2cda 100644 --- a/doc/en/getting-started.rst +++ b/doc/en/getting-started.rst @@ -49,17 +49,17 @@ That's it. You can execute the test function now:: platform linux -- Python 3.5.2, pytest-3.0.7, py-1.4.32, pluggy-0.4.0 rootdir: $REGENDOC_TMPDIR, inifile: collected 1 items - + test_sample.py F - + ======= FAILURES ======== _______ test_answer ________ - + def test_answer(): > assert func(3) == 5 E assert 4 == 5 E + where 4 = func(3) - + test_sample.py:5: AssertionError ======= 1 failed in 0.12 seconds ======== @@ -128,15 +128,15 @@ run the module by passing its filename:: .F ======= FAILURES ======== _______ TestClass.test_two ________ - + self = - + def test_two(self): x = "hello" > assert hasattr(x, 'check') E AssertionError: assert False E + where False = hasattr('hello', 'check') - + test_class.py:8: AssertionError 1 failed, 1 passed in 0.12 seconds @@ -165,14 +165,14 @@ before performing the test function call. Let's just run it:: F ======= FAILURES ======== _______ test_needsfiles ________ - + tmpdir = local('PYTEST_TMPDIR/test_needsfiles0') - + def test_needsfiles(tmpdir): print (tmpdir) > assert 0 E assert 0 - + test_tmpdir.py:3: AssertionError --------------------------- Captured stdout call --------------------------- PYTEST_TMPDIR/test_needsfiles0 @@ -191,8 +191,8 @@ Where to go next Here are a few suggestions where to go next: * :ref:`cmdline` for command line invocation examples -* :ref:`existingtestsuite` for working with pre-existing tests * :ref:`good practices ` for virtualenv, test layout +* :ref:`existingtestsuite` for working with pre-existing tests * :ref:`fixtures` for providing a functional baseline to your tests * :ref:`plugins` managing and writing plugins