diff options
| author | Tim Graham <timograham@gmail.com> | 2013-03-22 05:50:45 -0400 |
|---|---|---|
| committer | Tim Graham <timograham@gmail.com> | 2013-03-22 14:08:55 -0400 |
| commit | f7ca464039b4f21705a8a7074f6c542c3e4937b4 (patch) | |
| tree | 832a3d71b504a8ca19a28cb67fe3cb8660970bd2 /docs/topics/testing | |
| parent | 1363b418234d9af214ba9093014259fbb0ea2242 (diff) | |
[1.5.x] Added missing markup to docs.
Backport of 93cffc3b37 from master.
Diffstat (limited to 'docs/topics/testing')
| -rw-r--r-- | docs/topics/testing/overview.txt | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/docs/topics/testing/overview.txt b/docs/topics/testing/overview.txt index 7528ae141f..50c75ef729 100644 --- a/docs/topics/testing/overview.txt +++ b/docs/topics/testing/overview.txt @@ -965,8 +965,8 @@ This class provides some additional capabilities that can be useful for testing Web sites. Converting a normal :class:`unittest.TestCase` to a Django :class:`TestCase` is -easy: Just change the base class of your test from `'unittest.TestCase'` to -`'django.test.TestCase'`. All of the standard Python unit test functionality +easy: Just change the base class of your test from ``'unittest.TestCase'`` to +``'django.test.TestCase'``. All of the standard Python unit test functionality will continue to be available, but it will be augmented with some useful additions, including: @@ -1002,7 +1002,7 @@ This allows the use of automated test clients other than the client, to execute a series of functional tests inside a browser and simulate a real user's actions. -By default the live server's address is `'localhost:8081'` and the full URL +By default the live server's address is ``'localhost:8081'`` and the full URL can be accessed during the tests with ``self.live_server_url``. If you'd like to change the default address (in the case, for example, where the 8081 port is already taken) then you may pass a different one to the :djadmin:`test` command @@ -1109,7 +1109,7 @@ out the `full reference`_ for more details. (for example, just after clicking a link or submitting a form), you might need to check that a response is received by Selenium and that the next page is loaded before proceeding with further test execution. - Do this, for example, by making Selenium wait until the `<body>` HTML tag + Do this, for example, by making Selenium wait until the ``<body>`` HTML tag is found in the response (requires Selenium > 2.13): .. code-block:: python @@ -1126,7 +1126,7 @@ out the `full reference`_ for more details. The tricky thing here is that there's really no such thing as a "page load," especially in modern Web apps that generate HTML dynamically after the server generates the initial document. So, simply checking for the presence - of `<body>` in the response might not necessarily be appropriate for all + of ``<body>`` in the response might not necessarily be appropriate for all use cases. Please refer to the `Selenium FAQ`_ and `Selenium documentation`_ for more information. |