doc typo fixes from Victor Garcia, thanks!
This commit is contained in:
parent
2f2586af72
commit
27577170e1
|
@ -4,6 +4,8 @@ Changes between 2.0.1 and 2.0.2
|
|||
- fix issue24 - pytest_assertrepr_compare produces an in-line
|
||||
exception on python3
|
||||
|
||||
- fixed some typos in the docs (thanks Victor)
|
||||
|
||||
Changes between 2.0.0 and 2.0.1
|
||||
----------------------------------------------
|
||||
|
||||
|
|
|
@ -117,7 +117,7 @@ Important Notes
|
|||
- py.test.collect.Directory does not exist anymore and it
|
||||
is not possible to provide an own "Directory" object.
|
||||
If you have used this and don't know what to do, get
|
||||
in contact. We'll figure someting out.
|
||||
in contact. We'll figure something out.
|
||||
|
||||
Note that pytest_collect_directory() is still called but
|
||||
any return value will be ignored. This allows to keep
|
||||
|
|
|
@ -63,5 +63,5 @@ Changes between 2.0.0 and 2.0.1
|
|||
collection-before-running semantics were not
|
||||
setup as with pytest 1.3.4. Note, however, that
|
||||
the recommended and much cleaner way to do test
|
||||
parametraization remains the "pytest_generate_tests"
|
||||
parametrization remains the "pytest_generate_tests"
|
||||
mechanism, see the docs.
|
||||
|
|
|
@ -91,7 +91,7 @@ Making use of context-sensitive comparisons
|
|||
|
||||
.. versionadded:: 2.0
|
||||
|
||||
py.test has rich support for providing context-sensitive informations
|
||||
py.test has rich support for providing context-sensitive information
|
||||
when it encounters comparisons. For example::
|
||||
|
||||
# content of test_assert2.py
|
||||
|
|
|
@ -58,7 +58,7 @@ you can add this to your root directory::
|
|||
[pytest]
|
||||
addopts = -rsxX -q
|
||||
|
||||
From now on, running ``py.test`` will implicitely add
|
||||
From now on, running ``py.test`` will implicitly add
|
||||
the specified options.
|
||||
|
||||
builtin configuration file options
|
||||
|
|
|
@ -48,7 +48,7 @@ the output.
|
|||
example: decorating a funcarg in a test module
|
||||
--------------------------------------------------------------
|
||||
|
||||
For larger scale setups it's sometimes useful to decorare
|
||||
For larger scale setups it's sometimes useful to decorate
|
||||
a funcarg just for a particular test module. We can
|
||||
extend the `accept example`_ by putting this in our test module:
|
||||
|
||||
|
|
|
@ -67,7 +67,7 @@ let's run the full monty::
|
|||
As expected when running the full range of ``param1`` values
|
||||
we'll get an error on the last one.
|
||||
|
||||
Defering the setup of parametrizing resources
|
||||
Deferring the setup of parametrizing resources
|
||||
---------------------------------------------------
|
||||
|
||||
.. regendoc:wipe
|
||||
|
@ -271,7 +271,7 @@ checking serialization between Python interpreters
|
|||
--------------------------------------------------------------
|
||||
|
||||
Here is a stripped down real-life example of using parametrized
|
||||
testing for testing serialization betwee different interpreters.
|
||||
testing for testing serialization between different interpreters.
|
||||
We define a ``test_basic_objects`` function which is to be run
|
||||
with different sets of arguments for its three arguments::
|
||||
|
||||
|
|
|
@ -13,7 +13,7 @@ Why a ``py.test`` instead of a ``pytest`` command?
|
|||
++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
Some historic, some practical reasons: ``py.test`` used to be part of
|
||||
the ``py`` package which provided several developer utitilities,
|
||||
the ``py`` package which provided several developer utilities,
|
||||
all starting with ``py.<TAB>``, providing nice TAB-completion. If
|
||||
you install ``pip install pycmd`` you get these tools from a separate
|
||||
package. These days the command line tool could be called ``pytest``
|
||||
|
@ -53,7 +53,7 @@ When an ``assert`` 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).
|
||||
``py.test --no-assert`` turns off assert re-intepretation.
|
||||
``py.test --no-assert`` turns off assert re-interpretation.
|
||||
Sidenote: it is good practise to avoid asserts with side effects.
|
||||
|
||||
.. _`py namespaces`: index.html
|
||||
|
@ -125,8 +125,8 @@ Issues with py.test, multiprocess and setuptools?
|
|||
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
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 ``if __name__=='__main__'``
|
||||
by pickling and thus implicitly re-import a lot of local modules.
|
||||
Unfortunately, setuptools-0.6.11 does not ``if __name__=='__main__'``
|
||||
protect its generated command line script. This leads to infinite
|
||||
recursion when running a test that instantiates Processes.
|
||||
|
||||
|
|
|
@ -14,20 +14,20 @@ the ``pytest`` package itself. This way you get a much more reproducible
|
|||
environment. A good tool to help you automate test runs against multiple
|
||||
dependency configurations or Python interpreters is `tox`_,
|
||||
independently created by the main py.test author. The latter
|
||||
is also useful for integration with the continous integration
|
||||
is also useful for integration with the continuous integration
|
||||
server Hudson_.
|
||||
|
||||
.. _`virtualenv`: http://pypi.python.org/pypi/virtualenv
|
||||
.. _`buildout`: http://www.buildout.org/
|
||||
.. _pip: http://pypi.python.org/pypi/pip
|
||||
|
||||
Use tox and Continous Integration servers
|
||||
Use tox and Continuous Integration servers
|
||||
-------------------------------------------------
|
||||
|
||||
If you are (often) releasing code to the public you
|
||||
may want to look into `tox`_, the virtualenv test automation
|
||||
tool and its `pytest support <http://codespeak.net/tox/example/pytest.html>`_.
|
||||
The basic idea is to generate a JUnitXML file through the ``--junitxml=PATH`` option and have a continous integration server like Hudson_ pick it up.
|
||||
The basic idea is to generate a JUnitXML file through the ``--junitxml=PATH`` option and have a continuous integration server like Hudson_ pick it up.
|
||||
|
||||
.. _standalone:
|
||||
.. _`genscript method`:
|
||||
|
|
|
@ -7,7 +7,7 @@ Welcome to ``py.test``!
|
|||
- **a mature fully featured testing tool**
|
||||
|
||||
- runs on Posix/Windows, Python 2.4-3.2, PyPy and Jython
|
||||
- continously `tested on many Python interpreters <http://hudson.testrun.org/view/pytest/job/pytest/>`_
|
||||
- continuously `tested on many Python interpreters <http://hudson.testrun.org/view/pytest/job/pytest/>`_
|
||||
- used in :ref:`many projects and organisations <projects>`, ranging from 10 to 10000 tests
|
||||
- has :ref:`comprehensive documentation <toc>`
|
||||
- comes with :ref:`tested examples <examples>`
|
||||
|
@ -27,7 +27,7 @@ Welcome to ``py.test``!
|
|||
- advanced :ref:`skip and xfail`
|
||||
- generic :ref:`marking and test selection <mark>`
|
||||
- can :ref:`distribute tests to multiple CPUs <xdistcpu>` through :ref:`xdist plugin <xdist>`
|
||||
- can :ref:`continously re-run failing tests <looponfailing>`
|
||||
- can :ref:`continuously re-run failing tests <looponfailing>`
|
||||
- many :ref:`builtin helpers <pytest helpers>`
|
||||
- flexible :ref:`Python test discovery`
|
||||
- unique :ref:`dependency injection through funcargs <funcargs>`
|
||||
|
@ -40,7 +40,7 @@ Welcome to ``py.test``!
|
|||
- supports extended :ref:`xUnit style setup <xunitsetup>`
|
||||
- supports domain-specific :ref:`non-python tests`
|
||||
- supports generating testing coverage reports
|
||||
- `Javasript unit- and functional testing`_
|
||||
- `Javascript unit- and functional testing`_
|
||||
|
||||
- **extensive plugin and customization system**
|
||||
|
||||
|
@ -48,7 +48,7 @@ Welcome to ``py.test``!
|
|||
- customizations can be per-directory, per-project or per PyPI released plugins
|
||||
- it is easy to add command line options or do other kind of add-ons and customizations.
|
||||
|
||||
.. _`Javasript unit- and functional testing`: http://pypi.python.org/pypi/oejskit
|
||||
.. _`Javascript unit- and functional testing`: http://pypi.python.org/pypi/oejskit
|
||||
|
||||
.. _`easy`: http://bruynooghe.blogspot.com/2009/12/skipping-slow-test-by-default-in-pytest.html
|
||||
|
||||
|
|
|
@ -47,7 +47,7 @@ earlier than further away ones.
|
|||
.. Note::
|
||||
If you have ``conftest.py`` files which do not reside in a
|
||||
python package directory (i.e. one containing an ``__init__.py``) then
|
||||
"import conftest" can be ambigous because there might be other
|
||||
"import conftest" can be ambiguous because there might be other
|
||||
``conftest.py`` files as well on your PYTHONPATH or ``sys.path``.
|
||||
It is thus good practise for projects to either put ``conftest.py``
|
||||
under a package scope or to never import anything from a
|
||||
|
@ -79,7 +79,7 @@ there is no need to activate it. Here is a list of known plugins:
|
|||
coverage reporting, compatible with distributed testing
|
||||
|
||||
* `pytest-pep8 <http://pypi.python.org/pypi/pytest-pep8>`_:
|
||||
a ``--pep8`` option to enable PEP8 compliancy checking.
|
||||
a ``--pep8`` option to enable PEP8 compliance checking.
|
||||
|
||||
* `oejskit <http://pypi.python.org/pypi/oejskit>`_:
|
||||
a plugin to run javascript unittests in life browsers
|
||||
|
|
|
@ -147,7 +147,7 @@ within test or setup code. Example::
|
|||
|
||||
def test_function():
|
||||
if not valid_config():
|
||||
pytest.xfail("unsuppored configuration")
|
||||
pytest.xfail("unsupported configuration")
|
||||
|
||||
|
||||
skipping on a missing import dependency
|
||||
|
@ -159,7 +159,7 @@ or within a test or test setup function::
|
|||
docutils = pytest.importorskip("docutils")
|
||||
|
||||
If ``docutils`` cannot be imported here, this will lead to a
|
||||
skip outcome of the test. You can also skip dependeing if
|
||||
skip outcome of the test. You can also skip depending if
|
||||
if a library does not come with a high enough version::
|
||||
|
||||
docutils = pytest.importorskip("docutils", minversion="0.3")
|
||||
|
@ -175,5 +175,5 @@ within test or setup code. Example::
|
|||
|
||||
def test_function():
|
||||
if not valid_config():
|
||||
pytest.skip("unsuppored configuration")
|
||||
pytest.skip("unsupported configuration")
|
||||
|
||||
|
|
|
@ -30,7 +30,7 @@ test parametrization:
|
|||
|
||||
distributed testing:
|
||||
|
||||
- `simultanously test your code on all platforms`_ (blog entry)
|
||||
- `simultaneously test your code on all platforms`_ (blog entry)
|
||||
|
||||
plugin specific examples:
|
||||
|
||||
|
@ -42,7 +42,7 @@ plugin specific examples:
|
|||
.. _`many examples in the docs for plugins`: plugin/index.html
|
||||
.. _`monkeypatch plugin`: plugin/monkeypatch.html
|
||||
.. _`application setup in test functions with funcargs`: funcargs.html#appsetup
|
||||
.. _`simultanously test your code on all platforms`: http://tetamap.wordpress.com/2009/03/23/new-simultanously-test-your-code-on-all-platforms/
|
||||
.. _`simultaneously test your code on all platforms`: http://tetamap.wordpress.com/2009/03/23/new-simultanously-test-your-code-on-all-platforms/
|
||||
.. _`monkey patching done right`: http://tetamap.wordpress.com/2009/03/03/monkeypatching-in-unit-tests-done-right/
|
||||
.. _`putting test-hooks into local or global plugins`: http://tetamap.wordpress.com/2009/05/14/putting-test-hooks-into-local-and-global-plugins/
|
||||
.. _`parametrizing tests, generalized`: http://tetamap.wordpress.com/2009/05/13/parametrizing-python-tests-generalized/
|
||||
|
|
|
@ -17,7 +17,7 @@ customize_: configuration, customization, extensions
|
|||
|
||||
changelog_: history of changes covering last releases
|
||||
|
||||
**Continous Integration of py.test's own tests and plugins with Hudson**:
|
||||
**Continuous Integration of py.test's own tests and plugins with Hudson**:
|
||||
|
||||
`http://hudson.testrun.org/view/pytest`_
|
||||
|
||||
|
|
|
@ -5,7 +5,7 @@ Mission
|
|||
py.test strives to make testing a fun and no-boilerplate effort.
|
||||
|
||||
The tool is distributed as part of the `py` package which contains supporting APIs that
|
||||
are also useable independently. The project independent ``py.test`` command line tool helps you to:
|
||||
are also usable independently. The project independent ``py.test`` command line tool helps you to:
|
||||
|
||||
* rapidly collect and run tests
|
||||
* run unit- or doctests, functional or integration tests
|
||||
|
|
|
@ -202,7 +202,7 @@ do normal site initialisation so that the environment variables can be detected
|
|||
started.
|
||||
|
||||
|
||||
Acknowledgements
|
||||
Acknowledgments
|
||||
----------------
|
||||
|
||||
Holger Krekel for pytest with its distributed testing support.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
pytest_oejskit plugin (EXTERNAL)
|
||||
==========================================
|
||||
|
||||
The `oejskit`_ offers a py.test plugin for running Javascript tests in life browers. Running inside the browsers comes with some speed cost, on the other hand it means for example the code is tested against the real-word DOM implementations.
|
||||
The `oejskit`_ offers a py.test plugin for running Javascript tests in life browsers. Running inside the browsers comes with some speed cost, on the other hand it means for example the code is tested against the real-word DOM implementations.
|
||||
The approach enables to write integration tests such that the JavaScript code is tested against server-side Python code mocked as necessary. Any server-side framework that can already be exposed through WSGI (or for which a subset of WSGI can be written to accommodate the jskit own needs) can play along.
|
||||
|
||||
For more info and download please visit the `oejskit PyPI`_ page.
|
||||
|
|
|
@ -129,7 +129,7 @@ put options values in a ``conftest.py`` file like this::
|
|||
option_tx = ['ssh=myhost//python=python2.5', 'popen//python=python2.5']
|
||||
option_dist = True
|
||||
|
||||
Any commandline ``--tx`` specifictions will add to the list of
|
||||
Any commandline ``--tx`` specifications will add to the list of
|
||||
available execution environments.
|
||||
|
||||
Specifying "rsync" dirs in a conftest.py
|
||||
|
|
|
@ -56,7 +56,7 @@ the default base temporary directory
|
|||
|
||||
Temporary directories are by default created as sub directories of
|
||||
the system temporary directory. The base name will be ``pytest-NUM`` where
|
||||
``NUM`` will be incremenated with each test run. Moreover, entries older
|
||||
``NUM`` will be incremented with each test run. Moreover, entries older
|
||||
than 3 temporary directories will be removed.
|
||||
|
||||
You can override the default temporary directory setting like this::
|
||||
|
|
|
@ -101,7 +101,7 @@ you :ref:`disable capturing`.
|
|||
creating JUnitXML format files
|
||||
----------------------------------------------------
|
||||
|
||||
To create result files which can be read by Hudson_ or other Continous
|
||||
To create result files which can be read by Hudson_ or other Continuous
|
||||
integration servers, use this invocation::
|
||||
|
||||
py.test --junitxml=path
|
||||
|
|
|
@ -36,7 +36,7 @@ Install the plugin with::
|
|||
|
||||
pip install pytest-xdist
|
||||
|
||||
or use the package in develope/in-place mode with
|
||||
or use the package in develop/in-place mode with
|
||||
a checkout of the `pytest-xdist repository`_ ::
|
||||
|
||||
python setup.py develop
|
||||
|
@ -157,7 +157,7 @@ at once. The specifications strings use the `xspec syntax`_.
|
|||
Specifying test exec environments in an ini file
|
||||
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
pytest (since version 2.0) supports ini-style cofiguration.
|
||||
pytest (since version 2.0) supports ini-style configuration.
|
||||
You can for example make running with three subprocesses
|
||||
your default like this::
|
||||
|
||||
|
|
Loading…
Reference in New Issue