mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-23 21:59:11 +00:00
Code Issues 32 Releases Wiki Activity

[4.2.x] Refs #34140 -- Applied rst code-block to non-Python examples.

Browse Source 
Thanks to J.V. Zammit, Paolo Melchiorre, and Mariusz Felisiak for
reviews.

Backport of 534ac48297 from main.
This commit is contained in:
Carlton Gibson
2023-02-09 16:48:46 +01:00
committed by Mariusz Felisiak
parent 4a89aa25c9
commit b784768eef
120 changed files with 3998 additions and 1397 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/topics/testing/advanced.txt
View File

@@ -414,7 +414,9 @@ you may want to use the Django test runner to run your own test suite
and thus benefit from the Django testing infrastructure.
A common practice is a *tests* directory next to the application code, with the
following structure::
following structure:
.. code-block:: text
runtests.py
polls/
@@ -869,12 +871,16 @@ the coverage of your tests.
Django can be easily integrated with `coverage.py`_, a tool for measuring code
coverage of Python programs. First, `install coverage.py`_. Next, run the
following from your project folder containing ``manage.py``::
following from your project folder containing ``manage.py``:
.. code-block:: shell
coverage run --source='.' manage.py test myapp
This runs your tests and collects coverage data of the executed files in your
project. You can see a report of this data by typing following command::
project. You can see a report of this data by typing following command:
.. code-block:: shell
coverage report

28
docs/topics/testing/overview.txt
View File

@@ -75,7 +75,9 @@ Running tests
=============
Once you've written tests, run them using the :djadmin:`test` command of
your project's ``manage.py`` utility::
your project's ``manage.py`` utility:
.. code-block:: shell
$ ./manage.py test
@@ -85,7 +87,9 @@ any file named ``test*.py`` under the current working directory.
You can specify particular tests to run by supplying any number of "test
labels" to ``./manage.py test``. Each test label can be a full Python dotted
path to a package, module, ``TestCase`` subclass, or test method. For instance::
path to a package, module, ``TestCase`` subclass, or test method. For instance:
.. code-block:: shell
# Run all the tests in the animals.tests module
$ ./manage.py test animals.tests
@@ -100,13 +104,17 @@ path to a package, module, ``TestCase`` subclass, or test method. For instance::
$ ./manage.py test animals.tests.AnimalTestCase.test_animals_can_speak
You can also provide a path to a directory to discover tests below that
directory::
directory:
.. code-block:: shell
$ ./manage.py test animals/
You can specify a custom filename pattern match using the ``-p`` (or
``--pattern``) option, if your test files are named differently from the
``test*.py`` pattern::
``test*.py`` pattern:
.. code-block:: shell
$ ./manage.py test --pattern="tests_*.py"
@@ -288,7 +296,9 @@ Understanding the test output
When you run your tests, you'll see a number of messages as the test runner
prepares itself. You can control the level of detail of these messages with the
``verbosity`` option on the command line::
``verbosity`` option on the command line:
.. code-block:: shell
Creating test database...
Creating table myapp_animal
@@ -298,7 +308,9 @@ This tells you that the test runner is creating a test database, as described
in the previous section.
Once the test database has been created, Django will run your tests.
If everything goes well, you'll see something like this::
If everything goes well, you'll see something like this:
.. code-block:: shell
----------------------------------------------------------------------
Ran 22 tests in 0.221s
@@ -306,7 +318,9 @@ If everything goes well, you'll see something like this::
OK
If there are test failures, however, you'll see full details about which tests
failed::
failed:
.. code-block:: shell
======================================================================
FAIL: test_was_published_recently_with_future_poll (polls.tests.PollMethodTests)

78
docs/topics/testing/tools.txt
View File

@@ -48,7 +48,9 @@ Overview and a quick example
----------------------------
To use the test client, instantiate ``django.test.Client`` and retrieve
web pages::
web pages:
.. code-block:: pycon
>>> from django.test import Client
>>> c = Client()
@@ -70,11 +72,15 @@ Note a few important things about how the test client works:
framework. This helps make the unit tests run quickly.
* When retrieving pages, remember to specify the *path* of the URL, not the
whole domain. For example, this is correct::
whole domain. For example, this is correct:
.. code-block:: pycon
>>> c.get('/login/')
This is incorrect::
This is incorrect:
.. code-block:: pycon
>>> c.get('https://www.example.com/login/')
@@ -102,7 +108,9 @@ Note a few important things about how the test client works:
checks, you can create an instance of the test client that
enforces CSRF checks. To do this, pass in the
``enforce_csrf_checks`` argument when you construct your
client::
client:
.. code-block:: pycon
>>> from django.test import Client
>>> csrf_client = Client(enforce_csrf_checks=True)
@@ -160,17 +168,23 @@ Use the ``django.test.Client`` class to make requests.
object, which is documented below.
The key-value pairs in the ``data`` dictionary are used to create a GET
data payload. For example::
data payload. For example:
.. code-block:: pycon
>>> c = Client()
>>> c.get('/customers/details/', {'name': 'fred', 'age': 7})
...will result in the evaluation of a GET request equivalent to::
...will result in the evaluation of a GET request equivalent to:
.. code-block:: text
/customers/details/?name=fred&age=7
The ``headers`` parameter can be used to specify headers to be sent in
the request. For example::
the request. For example:
.. code-block:: pycon
>>> c = Client()
>>> c.get('/customers/details/', {'name': 'fred', 'age': 7},
@@ -182,17 +196,21 @@ Use the ``django.test.Client`` class to make requests.
Arbitrary keyword arguments set WSGI
:pep:`environ variables <3333#environ-variables>`. For example, headers
to set the script name::
to set the script name:
.. code-block:: pycon
>>> c = Client()
>>> c.get("/", SCRIPT_NAME="/app/")
If you already have the GET arguments in URL-encoded form, you can
use that encoding instead of using the data argument. For example,
the previous GET request could also be posed as::
the previous GET request could also be posed as:
>>> c = Client()
>>> c.get('/customers/details/?name=fred&age=7')
.. code-block:: pycon
>>> c = Client()
>>> c.get('/customers/details/?name=fred&age=7')
If you provide a URL with both an encoded GET data and a data argument,
the data argument will take precedence.
@@ -202,7 +220,9 @@ Use the ``django.test.Client`` class to make requests.
containing tuples of the intermediate urls and status codes.
If you had a URL ``/redirect_me/`` that redirected to ``/next/``, that
redirected to ``/final/``, this is what you'd see::
redirected to ``/final/``, this is what you'd see:
.. code-block:: pycon
>>> response = c.get('/redirect_me/', follow=True)
>>> response.redirect_chain
@@ -221,7 +241,9 @@ Use the ``django.test.Client`` class to make requests.
``Response`` object, which is documented below.
The key-value pairs in the ``data`` dictionary are used to submit POST
data. For example::
data. For example:
.. code-block:: pycon
>>> c = Client()
>>> c.post('/login/', {'name': 'fred', 'passwd': 'secret'})
@@ -264,7 +286,9 @@ Use the ``django.test.Client`` class to make requests.
provide the file field name as a key, and a file handle to the file you
wish to upload as a value. For example, if your form has fields
``name`` and ``attachment``, the latter a
:class:`~django.forms.FileField`::
:class:`~django.forms.FileField`:
.. code-block:: pycon
>>> c = Client()
>>> with open('wishlist.doc', 'rb') as fp:
@@ -275,7 +299,9 @@ Use the ``django.test.Client`` class to make requests.
:class:`~django.db.models.ImageField`, the object needs a ``name``
attribute that passes the
:data:`~django.core.validators.validate_image_file_extension` validator.
For example::
For example:
.. code-block:: pycon
>>> from io import BytesIO
>>> img = BytesIO(
@@ -300,9 +326,11 @@ Use the ``django.test.Client`` class to make requests.
If the URL you request with a POST contains encoded parameters, these
parameters will be made available in the request.GET data. For example,
if you were to make the request::
if you were to make the request:
>>> c.post('/login/?visitor=true', {'name': 'fred', 'passwd': 'secret'})
.. code-block:: pycon
>>> c.post('/login/?visitor=true', {'name': 'fred', 'passwd': 'secret'})
... the view handling this request could interrogate request.POST
to retrieve the username and password, and could interrogate request.GET
@@ -419,7 +447,9 @@ Use the ``django.test.Client`` class to make requests.
(which is configured by your :setting:`AUTHENTICATION_BACKENDS`
setting). If you're using the standard authentication backend provided
by Django (``ModelBackend``), ``credentials`` should be the user's
username and password, provided as keyword arguments::
username and password, provided as keyword arguments:
.. code-block:: pycon
>>> c = Client()
>>> c.login(username='fred', password='secret')
@@ -513,7 +543,9 @@ Specifically, a ``Response`` object has the following attributes:
Regardless of the number of templates used during rendering, you can
retrieve context values using the ``[]`` operator. For example, the
context variable ``name`` could be retrieved using::
context variable ``name`` could be retrieved using:
.. code-block:: pycon
>>> response = client.get('/foo/')
>>> response.context['name']
@@ -545,7 +577,9 @@ Specifically, a ``Response`` object has the following attributes:
.. method:: json(**kwargs)
The body of the response, parsed as JSON. Extra keyword arguments are
passed to :func:`json.loads`. For example::
passed to :func:`json.loads`. For example:
.. code-block:: pycon
>>> response = client.get('/foo/')
>>> response.json()['name']
@@ -1970,7 +2004,9 @@ test client, with two exceptions:
* The ``follow`` parameter is not supported.
* Headers passed as ``extra`` keyword arguments should not have the ``HTTP_``
prefix required by the synchronous client (see :meth:`Client.get`). For
example, here is how to set an HTTP ``Accept`` header::
example, here is how to set an HTTP ``Accept`` header:
.. code-block:: pycon
>>> c = AsyncClient()
>>> c.get(