mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-08-31 07:47:37 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

Refs #27392 -- Removed "Tests that", "Ensures that", etc. from test docstrings.

Browse source
This commit is contained in:
za 2016-10-27 14:53:39 +07:00 • committed by Tim Graham
parent 4bb70cbcc6
commit 321e94fa41
185 changed files with 1216 additions and 1528 deletions
Download patch file Download diff file Expand all files Collapse all files

12
tests/expressions/tests.py
View file

@ -349,9 +349,9 @@ class BasicExpressionsTests(TestCase):
self.assertSequenceEqual(qs, [e2, e3])
def test_ticket_18375_join_reuse(self):
# Test that reverse multijoin F() references and the lookup target
# the same join. Pre #18375 the F() join was generated first, and the
# lookup couldn't reuse that join.
# Reverse multijoin F() references and the lookup target the same join.
# Pre #18375 the F() join was generated first and the lookup couldn't
# reuse that join.
qs = Employee.objects.filter(
company_ceo_set__num_chairs=F('company_ceo_set__num_employees'))
self.assertEqual(str(qs.query).count('JOIN'), 1)
@ -379,7 +379,7 @@ class BasicExpressionsTests(TestCase):
self.assertEqual(str(qs.query).count('JOIN'), 1)
def test_ticket_18375_chained_filters(self):
# Test that F() expressions do not reuse joins from previous filter.
# F() expressions do not reuse joins from previous filter.
qs = Employee.objects.filter(
company_ceo_set__num_employees=F('pk')
).filter(
@ -553,7 +553,7 @@ class ExpressionsTests(TestCase):
def test_patterns_escape(self):
r"""
Test that special characters (e.g. %, _ and \) stored in database are
Special characters (e.g. %, _ and \) stored in database are
properly escaped when using a pattern lookup with an expression
refs #16731
"""
@ -585,7 +585,7 @@ class ExpressionsTests(TestCase):
def test_insensitive_patterns_escape(self):
r"""
Test that special characters (e.g. %, _ and \) stored in database are
Special characters (e.g. %, _ and \) stored in database are
properly escaped when using a case insensitive pattern lookup with an
expression -- refs #16731
"""