From 12a2a231005dd965732a8321add66bf1f2387944 Mon Sep 17 00:00:00 2001 From: Adrian Holovaty Date: Mon, 14 Mar 2011 05:34:28 +0000 Subject: [PATCH] Reworded part of 'Running only some of the tests' in docs/internals/contributing.txt git-svn-id: http://code.djangoproject.com/svn/django/trunk@15799 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/internals/contributing.txt | 43 ++++++++++++++++++--------------- 1 file changed, 23 insertions(+), 20 deletions(-) diff --git a/docs/internals/contributing.txt b/docs/internals/contributing.txt index 6e40b1f3b1..6e14083dbe 100644 --- a/docs/internals/contributing.txt +++ b/docs/internals/contributing.txt @@ -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 ` 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 ` * 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."