mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-24 14:16:09 +00:00
Code Issues 32 Releases Wiki Activity

Fixed incorrect formatting for inline pluralized code references in docs.

Browse Source
This commit is contained in:
Clifford Gama
2025-03-13 20:18:35 +02:00
committed by GitHub
parent e7a9d756ee
commit efe3ca09e0
11 changed files with 64 additions and 58 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
docs/intro/tutorial05.txt
View File

@@ -461,11 +461,11 @@ Testing our new view
--------------------
Now you can satisfy yourself that this behaves as expected by firing up
``runserver``, loading the site in your browser, creating ``Questions`` with
dates in the past and future, and checking that only those that have been
published are listed. You don't want to have to do that *every single time you
make any change that might affect this* - so let's also create a test, based on
our :djadmin:`shell` session above.
``runserver``, loading the site in your browser, creating a few ``Question``
entries with dates in the past and future, and checking that only those that
have been published are listed. You don't want to have to do that *every single
time you make any change that might affect this* - so let's also create a test,
based on our :djadmin:`shell` session above.
Add the following to ``polls/tests.py``:
@@ -626,14 +626,14 @@ create a new test class for that view. It'll be very similar to what we have
just created; in fact there will be a lot of repetition.
We could also improve our application in other ways, adding tests along the
way. For example, it's silly that ``Questions`` can be published on the site
that have no ``Choices``. So, our views could check for this, and exclude such
``Questions``. Our tests would create a ``Question`` without ``Choices`` and
then test that it's not published, as well as create a similar ``Question``
*with* ``Choices``, and test that it *is* published.
way. For example, it's pointless that a ``Question`` with no related ``Choice``
can be published on the site. So, our views could check for this, and exclude
such ``Question`` objects. Our tests would create a ``Question`` without a
``Choice``, and then test that it's not published, as well as create a similar
``Question`` *with* at least one ``Choice``, and test that it *is* published.
Perhaps logged-in admin users should be allowed to see unpublished
``Questions``, but not ordinary visitors. Again: whatever needs to be added to
Perhaps logged-in admin users should be allowed to see unpublished ``Question``
entries, but not ordinary visitors. Again: whatever needs to be added to
the software to accomplish this should be accompanied by a test, whether you
write the test first and then make the code pass the test, or work out the
logic in your code first and then write a test to prove it.
@@ -653,9 +653,10 @@ once and then forget about it. It will continue performing its useful function
as you continue to develop your program.
Sometimes tests will need to be updated. Suppose that we amend our views so that
only ``Questions`` with ``Choices`` are published. In that case, many of our
existing tests will fail - *telling us exactly which tests need to be amended to
bring them up to date*, so to that extent tests help look after themselves.
only ``Question`` entries with associated ``Choice`` instances are published.
In that case, many of our existing tests will fail - *telling us exactly which
tests need to be amended to bring them up to date*, so to that extent tests
help look after themselves.
At worst, as you continue developing, you might find that you have some tests
that are now redundant. Even that's not a problem; in testing redundancy is