Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Reworded part of 'Running only some of the tests' in docs/internals/c…

…ontributing.txt

git-svn-id: http://code.djangoproject.com/svn/django/trunk@15799 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit 12a2a231005dd965732a8321add66bf1f2387944 1 parent 72c5733
Adrian Holovaty adrianholovaty authored
Showing with 23 additions and 20 deletions.
  1. +23 −20 docs/internals/contributing.txt
43 docs/internals/contributing.txt
View
@@ -7,21 +7,21 @@ it. We're passionate about helping Django users make the jump to contributing
members of the community, so there are many ways you can help Django's
development:
- * Blog about Django. We syndicate all the Django blogs we know about on
+ * Blog about Django. We syndicate all the Django blogs we know about on
the `community page`_; contact jacob@jacobian.org if you've got a blog
you'd like to see on that page.
- * Report bugs and request features in our `ticket tracker`_. Please read
+ * Report bugs and request features in our `ticket tracker`_. Please read
`Reporting bugs`_, below, for the details on how we like our bug reports
served up.
- * Submit patches for new and/or fixed behavior. Please read `Submitting
+ * Submit patches for new and/or fixed behavior. Please read `Submitting
patches`_, below, for details on how to submit a patch. If you're looking
for an easy way to start contributing to Django have a look at the
`easy-pickings`_ tickets.
* Join the `django-developers`_ mailing list and share your ideas for how
- to improve Django. We're always open to suggestions, although we're
+ to improve Django. We're always open to suggestions, although we're
likely to be skeptical of large-scale suggestions without some code to
back it up.
@@ -47,7 +47,7 @@ Reporting bugs
Well-written bug reports are *incredibly* helpful. However, there's a certain
amount of overhead involved in working with any bug tracking system so your
-help in keeping our ticket tracker as useful as possible is appreciated. In
+help in keeping our ticket tracker as useful as possible is appreciated. In
particular:
* **Do** read the :doc:`FAQ </faq/index>` to see if your issue might
@@ -65,7 +65,7 @@ particular:
A minimal example that illustrates the bug in a nice small test case
is the best possible bug report.
- * **Don't** use the ticket system to ask support questions. Use the
+ * **Don't** use the ticket system to ask support questions. Use the
`django-users`_ list, or the `#django`_ IRC channel for that.
* **Don't** use the ticket system to make large-scale feature requests.
@@ -74,7 +74,7 @@ particular:
* **Don't** reopen issues that have been marked "wontfix". This mark
means that the decision has been made that we can't or won't fix
- this particular issue. If you're not sure why, please ask
+ this particular issue. If you're not sure why, please ask
on `django-developers`_.
* **Don't** use the ticket tracker for lengthy discussions, because they're
@@ -1010,19 +1010,22 @@ dictionary for the applicable database.
Running only some of the tests
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Django's entire test suite takes a few minutes to run. To run a subset of the
-unit tests, append the names of the test modules to the ``runtests.py``
+Django's entire test suite takes a while to run, and running every single test
+could be redundant if, say, you just added a test to Django that you want to
+run quickly without running everything else. You can run a subset of the unit
+tests by appending the names of the test modules to ``runtests.py`` on the
command line.
-As an example, if you'd like to only run tests for generic relations and
+For example, if you'd like to run tests only for generic relations and
internationalization, type:
.. code-block:: bash
./runtests.py --settings=path.to.settings generic_relations i18n
-See the list of directories in ``tests/modeltests`` and
-``tests/regressiontests`` for module names.
+How do you find out the names of individual tests? Look in ``tests/modeltests``
+and ``tests/regressiontests`` -- each directory name there is the name of a
+test.
If you just want to run a particular class of tests, you can specify a list of
paths to individual test classes. For example, to run the ``TranslationTests``
@@ -1032,7 +1035,7 @@ of the ``i18n`` module, type:
./runtests.py --settings=path.to.settings i18n.TranslationTests
-You can specify an individual test like this:
+Going beyond that, you can specify an individual test method like this:
.. code-block:: bash
@@ -1052,7 +1055,7 @@ dependencies:
* memcached_, plus a :ref:`supported Python binding <memcached>`
* gettext_ (:ref:`gettext_on_windows`)
-If you want to test the memcached cache backend, you will also need to define
+If you want to test the memcached cache backend, you'll also need to define
a :setting:`CACHES` setting that points at your memcached instance.
Each of these dependencies is optional. If you're missing any of them, the
@@ -1086,10 +1089,10 @@ Requesting features
===================
We're always trying to make Django better, and your feature requests are a key
-part of that. Here are some tips on how to most effectively make a request:
+part of that. Here are some tips on how to make a request most effectively:
- * Request the feature on `django-developers`_, not in the ticket tracker;
- it'll get read more closely if it's on the mailing list.
+ * Request the feature on `django-developers`_, not in the ticket tracker.
+ It'll get read more closely if it's on the mailing list.
* Describe clearly and concisely what the missing feature is and how you'd
like to see it implemented. Include example code (non-functional is OK)
@@ -1102,8 +1105,8 @@ part of that. Here are some tips on how to most effectively make a request:
As with most open-source projects, code talks. If you are willing to write the
code for the feature yourself or if (even better) you've already written it,
-it's much more likely to be accepted. If it's a large feature that might need
-multiple developers we're always happy to give you an experimental branch in
+it's much more likely to be accepted. If it's a large feature that might need
+multiple developers, we're always happy to give you an experimental branch in
our repository; see below.
Branch policy
@@ -1289,7 +1292,7 @@ How we make decisions
Whenever possible, we strive for a rough consensus. To that end, we'll often
have informal votes on `django-developers`_ about a feature. In these votes we
follow the voting style invented by Apache and used on Python itself, where
-votes are given as +1, +0, -0, or -1. Roughly translated, these votes mean:
+votes are given as +1, +0, -0, or -1. Roughly translated, these votes mean:
* +1: "I love the idea and I'm strongly committed to it."
Please sign in to comment.
Something went wrong with that request. Please try again.