label code blocks

Author: boris

doc/en/builtin.rst

@@ -164,5 +164,7 @@ For information about fixtures, see :ref:`fixtures`. To see a complete list of a
 
 You can also interactively ask for help, e.g. by typing on the Python interactive prompt something like::
 
+.. code-block:: python
+
     import pytest
     help(pytest)

doc/en/cache.rst

@@ -35,6 +35,8 @@ Rerunning only failures or failures first
 
 First, let's create 50 test invocation of which only 2 fail::
 
+.. code-block:: python
+
     # content of test_50.py
     import pytest
 
@@ -185,6 +187,8 @@ pytest ``config`` object.  Here is a basic example plugin which
 implements a :ref:`fixture` which re-uses previously created state
 across pytest invocations::
 
+.. code-block:: python
+
     # content of test_caching.py
     import pytest
     import time

doc/en/capture.rst

@@ -51,6 +51,8 @@ Using print statements for debugging
 One primary benefit of the default capturing of stdout/stderr output
 is that you can use print statements for debugging::
 
+.. code-block:: python
+
     # content of test_module.py
 
     def setup_function(function):

doc/en/deprecations.rst

@@ -457,6 +457,8 @@ Internal classes accessed through ``Node``
 Access of ``Module``, ``Function``, ``Class``, ``Instance``, ``File`` and ``Item`` through ``Node`` instances now issue
 this warning::
 
+.. code-block:: text
+
     usage of Function.Module is deprecated, please use pytest.Module instead
 
 Users should just ``import pytest`` and access those objects using the ``pytest`` module.

doc/en/doctest.rst

@@ -193,6 +193,8 @@ your own fixtures to provide the tests that use them with context.
 ``doctest_namespace`` is a standard ``dict`` object into which you
 place the objects you want to appear in the doctest namespace::
 
+.. code-block:: python
+
     # content of conftest.py
     import numpy
     @pytest.fixture(autouse=True)
@@ -201,6 +203,8 @@ place the objects you want to appear in the doctest namespace::
 
 which can then be used in your doctests directly::
 
+.. code-block:: python
+
     # content of numpy.py
     def arange():
         """
@@ -221,6 +225,8 @@ Skipping tests dynamically
 
 You can use ``pytest.skip`` to dynamically skip doctests. For example::
 
+.. code-block:: text
+
     >>> import sys, pytest
     >>> if sys.platform.startswith('win'):
     ...     pytest.skip('this doctest does not work on Windows')

doc/en/example/parametrize.rst

@@ -21,13 +21,17 @@ Let's say we want to execute a test with different computation
 parameters and the parameter range shall be determined by a command
 line argument.  Let's first write a simple (do-nothing) computation test::
 
+.. code-block:: python
+
     # content of test_compute.py
 
     def test_compute(param1):
         assert param1 < 4
 
 Now we add a test configuration like this::
 
+.. code-block:: python
+
     # content of conftest.py
 
     def pytest_addoption(parser):
@@ -85,6 +89,8 @@ Numbers, strings, booleans and None will have their usual string representation
 used in the test ID. For other objects, pytest will make a string based on
 the argument name::
 
+.. code-block:: python
+
     # content of test_time.py
 
     import pytest
@@ -173,6 +179,8 @@ an add-on from Robert Collins for the standard unittest framework. We
 only have to work a bit to construct the correct arguments for pytest's
 :py:func:`Metafunc.parametrize`::
 
+.. code-block:: python
+
     # content of test_scenarios.py
 
     def pytest_generate_tests(metafunc):
@@ -246,6 +254,8 @@ connections or subprocess only when the actual test is run.
 Here is a simple example how you can achieve that, first
 the actual test requiring a ``db`` object::
 
+.. code-block:: python
+
     # content of test_backends.py
 
     import pytest
@@ -258,6 +268,8 @@ We can now add a test configuration that generates two invocations of
 the ``test_db_initialized`` function and also implements a factory that
 creates a database object for the actual test invocations::
 
+.. code-block:: python
+
     # content of conftest.py
     import pytest
 
@@ -329,6 +341,8 @@ two fixtures: ``x`` and ``y``. Here we give to indirect the list, which contains
 fixture ``x``. The indirect parameter will be applied to this argument only, and the value ``a``
 will be passed to respective fixture function::
 
+.. code-block:: python
+
     # content of test_indirect_list.py
 
     import pytest
@@ -372,6 +386,8 @@ Here is an example ``pytest_generate_tests`` function implementing a
 parametrization scheme similar to Michael Foord's `unittest
 parametrizer`_ but in a lot less code::
 
+.. code-block:: python
+
     # content of ./test_parametrize.py
     import pytest
 
@@ -449,6 +465,8 @@ and get skipped in case the implementation is not importable/available.  Let's
 say we have a "base" implementation and the other (possibly optimized ones)
 need to provide similar results::
 
+.. code-block:: python
+
     # content of conftest.py
 
     import pytest
@@ -463,18 +481,24 @@ need to provide similar results::
 
 And then a base implementation of a simple function::
 
+.. code-block:: python
+
     # content of base.py
     def func1():
         return 1
 
 And an optimized version::
 
+.. code-block:: python
+
     # content of opt1.py
     def func1():
         return 1.0001
 
 And finally a little test module::
 
+.. code-block:: python
+
     # content of test_module.py
 
     def test_func1(basemod, optmod):
@@ -581,6 +605,8 @@ in which some tests raise exceptions and others do not.
 It is helpful to define a no-op context manager ``does_not_raise`` to serve
 as a complement to ``raises``. For example::
 
+.. code-block:: python
+
     from contextlib import contextmanager
     import pytest
 
@@ -606,12 +632,18 @@ while the fourth should raise ``ZeroDivisionError``.
 If you're only supporting Python 3.7+, you can simply use ``nullcontext``
 to define ``does_not_raise``::
 
+.. code-block:: python
+
     from contextlib import nullcontext as does_not_raise
 
 Or, if you're supporting Python 3.3+ you can use::
 
+.. code-block:: python
+
     from contextlib import ExitStack as does_not_raise
 
 Or, if desired, you can ``pip install contextlib2`` and use::
 
+.. code-block:: python
+
     from contextlib2 import ExitStack as does_not_raise

doc/en/example/pythoncollection.rst

@@ -133,6 +133,8 @@ This would make ``pytest`` look for tests in files that match the ``check_*
 .py`` glob-pattern, ``Check`` prefixes in classes, and functions and methods
 that match ``*_check``. For example, if we have::
 
+.. code-block:: python
+
     # content of check_myapp.py
     class CheckMyApp(object):
         def simple_check(self):
@@ -240,6 +242,8 @@ imported. Moreover, there may files only importable by a specific python
 version. For such cases you can dynamically define files to be ignored by
 listing them in a ``conftest.py`` file::
 
+.. code-block:: python
+
     # content of conftest.py
     import sys
 
@@ -249,6 +253,8 @@ listing them in a ``conftest.py`` file::
 
 and then if you have a module file like this::
 
+.. code-block:: python
+
     # content of pkg/module_py2.py
     def test_only_on_python2():
         try:
@@ -258,6 +264,8 @@ and then if you have a module file like this::
 
 and a ``setup.py`` dummy file like this::
 
+.. code-block:: python
+
     # content of setup.py
     0/0  # will raise exception if imported
 
@@ -297,6 +305,8 @@ The following example ``conftest.py`` ignores the file ``setup.py`` and in
 addition all files that end with ``*_py2.py`` when executed with a Python 3
 interpreter::
 
+.. code-block:: python
+
     # content of conftest.py
     import sys
 

doc/en/example/special.rst

@@ -7,6 +7,8 @@ function which walks all collected tests and looks
 if their test class defines a ``callme`` method and
 calls it::
 
+.. code-block:: python
+
     # content of conftest.py
 
     import pytest
@@ -26,6 +28,8 @@ calls it::
 test classes may now define a ``callme`` method which
 will be called ahead of running any tests::
 
+.. code-block:: python
+
     # content of test_module.py
 
     class TestHello(object):

doc/en/existingtestsuite.rst

@@ -17,6 +17,8 @@ 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::
 
+.. code-block:: bash
+
     cd <repository>
     pip install -e .  # Environment dependent alternatives include
                       # 'python setup.py develop' and 'conda develop'