Refs #36485 -- Removed unnecessary parentheses in :meth: and :func: roles in docs.

3 files changed, 13 insertions, 13 deletions

diff --git a/docs/topics/testing/advanced.txt b/docs/topics/testing/advanced.txt
index 72373c6107..b6146253c1 100644
--- a/docs/topics/testing/advanced.txt
+++ b/docs/topics/testing/advanced.txt
@@ -19,10 +19,10 @@ a black box, with exactly known inputs, testing for specific outputs.
 The API for the :class:`~django.test.RequestFactory` is a slightly
 restricted subset of the test client API:
 
-* It only has access to the HTTP methods :meth:`~Client.get()`,
-  :meth:`~Client.post()`, :meth:`~Client.put()`,
-  :meth:`~Client.delete()`, :meth:`~Client.head()`,
-  :meth:`~Client.options()`, and :meth:`~Client.trace()`.
+* It only has access to the HTTP methods :meth:`~Client.get`,
+  :meth:`~Client.post`, :meth:`~Client.put`,
+  :meth:`~Client.delete`, :meth:`~Client.head`,
+  :meth:`~Client.options`, and :meth:`~Client.trace`.
 
 * These methods accept all the same arguments *except* for
   ``follow``. Since this is just a factory for producing
@@ -158,8 +158,8 @@ and the settings file includes a list of the domains supported by the project::
     ALLOWED_HOSTS = ["www.djangoproject.dev", "docs.djangoproject.dev", ...]
 
 Another option is to add the required hosts to :setting:`ALLOWED_HOSTS` using
-:meth:`~django.test.override_settings()` or
-:attr:`~django.test.SimpleTestCase.modify_settings()`. This option may be
+:meth:`~django.test.override_settings` or
+:attr:`~django.test.SimpleTestCase.modify_settings`. This option may be
 preferable in standalone apps that can't package their own settings file or
 for projects where the list of domains is not static (e.g., subdomains for
 multitenancy). For example, you could write a test for the domain
@@ -661,7 +661,7 @@ Methods
 
     Override this class method to add custom arguments accepted by the
     :djadmin:`test` management command. See
-    :py:meth:`argparse.ArgumentParser.add_argument()` for details about adding
+    :py:meth:`argparse.ArgumentParser.add_argument` for details about adding
     arguments to a parser.
 
 .. method:: DiscoverRunner.setup_test_environment(**kwargs)
diff --git a/docs/topics/testing/overview.txt b/docs/topics/testing/overview.txt
index a975ec099d..ac4110943a 100644
--- a/docs/topics/testing/overview.txt
+++ b/docs/topics/testing/overview.txt
@@ -208,7 +208,7 @@ with ability to share the database between threads.
     your code* anyway - rewrite your code so that it doesn't do this.
 
     This also applies to customized implementations of
-    :meth:`~django.apps.AppConfig.ready()`.
+    :meth:`~django.apps.AppConfig.ready`.
 
 .. seealso::
 
diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt
index dfe92f88eb..7574695b21 100644
--- a/docs/topics/testing/tools.txt
+++ b/docs/topics/testing/tools.txt
@@ -144,8 +144,8 @@ Use the ``django.test.Client`` class to make requests.
         but the ``headers`` parameter should be preferred for readability.
 
     The values from the ``headers``, ``query_params``, and ``extra`` keyword
-    arguments passed to :meth:`~django.test.Client.get()`,
-    :meth:`~django.test.Client.post()`, etc. have precedence over
+    arguments passed to :meth:`~django.test.Client.get`,
+    :meth:`~django.test.Client.post`, etc. have precedence over
     the defaults passed to the class constructor.
 
     The ``enforce_csrf_checks`` argument can be used to test CSRF
@@ -198,7 +198,7 @@ Use the ``django.test.Client`` class to make requests.
 
         ...will send the HTTP header ``HTTP_ACCEPT`` to the details view, which
         is a good way to test code paths that use the
-        :meth:`django.http.HttpRequest.accepts()` method.
+        :meth:`django.http.HttpRequest.accepts` method.
 
         Arbitrary keyword arguments set WSGI
         :pep:`environ variables <3333#environ-variables>`. For example, headers
@@ -456,7 +456,7 @@ Use the ``django.test.Client`` class to make requests.
         fixture. Remember that if you want your test user to have a password,
         you can't set the user's password by setting the password attribute
         directly -- you must use the
-        :meth:`~django.contrib.auth.models.User.set_password()` function to
+        :meth:`~django.contrib.auth.models.User.set_password` function to
         store a correctly hashed password. Alternatively, you can use the
         :meth:`~django.contrib.auth.models.UserManager.create_user` helper
         method to create a new user with a correctly hashed password.
@@ -882,7 +882,7 @@ end of each test. A consequence of this, however, is that some database
 behaviors cannot be tested within a Django ``TestCase`` class. For instance,
 you cannot test that a block of code is executing within a transaction, as is
 required when using
-:meth:`~django.db.models.query.QuerySet.select_for_update()`. In those cases,
+:meth:`~django.db.models.query.QuerySet.select_for_update`. In those cases,
 you should use ``TransactionTestCase``.
 
 ``TransactionTestCase`` and ``TestCase`` are identical except for the manner