Django从入门到实战：编写你的第一个 Django 应用（5）

在前几篇博客我们成功的构建了一个在线投票应用，

一周之际也在于周二（同一天啦【--忍住不笑--】），风雨无阻，雷打不动，继续走起学习。

在这一部分里我们将为它创建一些自动化测试。

 

自动化测试简介

测试，是用来检查代码正确性的一些简单的程序。

• 测试在不同的层次中都存在。有些测试只关注某个很小的细节（某个模型的某个方法的返回值是否满足预期？）
• 而另一些测试可能检查对某个软件的一系列操作（某一用户输入序列是否造成了预期的结果？）。
• 我们之前也使用 过 shell来测试某一方法的功能，或者运行某个应用并输入数据来检查它的行为。

自动化测试是由某个系统帮你自动完成的。当你创建好了一系列测试，每次修改应用代码后，就可以自动检查出修改后的代码是否还像你曾经预期的那样正常工作。你不需要花费大量时间来进行手动测试。

 

为什么你需要写测试

但是，为什么需要测试呢？又为什么是现在呢？

如果写一个投票应用是你想用 Django 完成的唯一工作，那你确实没必要学写测试。但是如果你还想写更复杂的项目，现在就是学习测试写法的最好时机了。

• 测试将节约你的时间————在更加复杂的应用中，各种组件之间的交互可能会及其的复杂。自动化测试能在几秒钟之内帮你完成判断「代码是否正常工作」。当某人写出错误的代码时，自动化测试还能帮助你定位错误代码的位置。
• 测试不仅能发现错误，而且能预防错误————如果没有测试，整个应用的行为意图会变得更加的不清晰。甚至当你在看自己写的代码时也是这样，有时候你需要仔细研读一段代码才能搞清楚它有什么用。
• 测试使你的代码更有吸引力————没有测试的代码不值得信任。其他的开发者希望在正式使用你的代码前看到它通过了测试，这是你需要写测试的另一个重要原因。
• 测试有利于团队协作————复杂的应用可能由团队维护。测试的存在保证了协作者不会不小心破坏了了你的代码（也保证你不会不小心弄坏他们的）。

综上所述，作为一个程序员谋生，必须擅长编写测试！

 

基础测试策略

有好几种不同的方法可以写测试。

• 遵循 "测试驱动" 的开发原则，在写代码之前先写测试。事实上，这和大多数人日常的做法是相吻合的。我们会先描述一个问题，然后写代码来解决它。「测试驱动」的开发方法只是将问题的描述抽象为了 Python 的测试样例。
• 更普遍的情况是，一个刚接触自动化测试的新手更倾向于先代码，后写测试。虽然提前写测试可能更好，但是晚点写起码也比没有强。
• 有时候很难决定从哪里开始下手写测试。如果是已经写了几千行 Python 代码，再选择从哪里开始写测试确实不怎么简单。那么在你下次修改代码（比如加新功能，或者修复 Bug）之前写个测试是比较合理且有效的。

所以，我们现在就开始写吧。

 

开始写我们的第一个测试

1. 首先得有个 Bug

幸运的是，我们的 polls 应用现在就有一个小 bug 需要被修复：

我们的要求是如果 Question 是在一天之内发布的， Question.was_published_recently() 方法将会返回 True ，然而现在这个方法在 Question 的 pub_date 字段比当前时间还晚时也会返回 True（这是个 Bug）。

使用下命令进入 shell 展示一下这个方法的日期bug：

python manage.py shell

>>> import datetime
>>> from django.utils import timezone
>>> from polls.models import Question
>>> #在将来30天内使用pub_date创建一个Question实例
>>> future_question = Question(pub_date=timezone.now() + datetime.timedelta(days=30))
>>> # 最近发布了吗？
>>> future_question.was_published_recently()
True

上述因为将来发生的是肯定不是最近发生的，所以代码明显是错误的，有bug。然后我们创建一个测试来暴露这个bug

 

2. 创建一个测试来暴露这个 bug

我们刚刚在 shell 里做的测试也就是自动化测试应该做的工作。所以我们来把它改写成自动化的吧。

按照惯例，Django 应用的测试应该写在应用的 tests.py 文件里。测试系统会自动的在所有以 tests 开头的文件里寻找并执行测试代码。

将下面的代码写入 polls 应用里的 tests.py 文件内：

# polls/tests.py

import datetime

from django.test import TestCase
from django.utils import timezone

from .models import Question


class QuestionModelTests(TestCase):

    def test_was_published_recently_with_future_question(self):
        """
        was_published_recently（）对于pub_date将来的问题返回False。
        """
        time = timezone.now() + datetime.timedelta(days=30)
        future_question = Question(pub_date=time)
        self.assertIs(future_question.was_published_recently(), False)

我们创建了一个 django.test.TestCase 的子类，并添加了一个方法，此方法创建一个 pub_date 时未来某天的 Question 实例。然后检查它的 was_published_recently() 方法的返回值——它 应该 是 False。

3. 运行测试

在终端中，我们通过输入以下代码运行测试：

 python manage.py test polls

你将会看到运行结果：

Creating test database for alias 'default'...
System check identified no issues (0 silenced).
F
======================================================================
FAIL: test_was_published_recently_with_future_question (polls.tests.QuestionModelTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/path/to/mysite/polls/tests.py", line 16, in test_was_published_recently_with_future_question
    self.assertIs(future_question.was_published_recently(), False)
AssertionError: True is not False

----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (failures=1)
Destroying test database for alias 'default'...

发生了什么呢？

以下是自动化测试的运行过程：

• python manage.py test polls 将会寻找 polls 应用里的测试代码
• 它找到了 django.test.TestCase 的一个子类
• 它创建一个特殊的数据库供测试使用
• 它在类中寻找测试方法——以 test 开头的方法。
• 在 test_was_published_recently_with_future_question 方法中，它创建了一个 pub_date 值为 30 天后的 Question 实例。
• 接着使用 assertls() 方法，发现 was_published_recently() 返回了 True，而我们期望它返回 False。

测试系统通知我们哪些测试样例失败了，和造成测试失败的代码所在的行号。

 

4. 修复这个 bug

我们早已知道，当 pub_date 为未来某天时， Question.was_published_recently() 应该返回 False。我们修改 models.py 里的方法，让它只在日期是过去式的时候才返回 True：

# polls/models.py

def was_published_recently(self):
    now = timezone.now()
    return now - datetime.timedelta(days=1) <= self.pub_date <= now

然后重新运行测试：

Creating test database for alias 'default'...
System check identified no issues (0 silenced).
.
----------------------------------------------------------------------
Ran 1 test in 0.001s

OK
Destroying test database for alias 'default'...

发现 bug 后，我们编写了能够暴露这个 bug 的自动化测试。在修复 bug 之后，我们的代码顺利的通过了测试。

将来，我们的应用可能会出现其他的问题，但是我们可以肯定的是，一定不会再次出现这个 bug，因为只要简单的运行一遍测试，就会立刻收到警告。我们可以认为应用的这一小部分代码永远是安全的。

 

5.更全面的测试

我们已经搞定一小部分了，现在可以考虑全面的测试 was_published_recently() 这个方法以确定它的安全性，然后就可以把这个方法稳定下来了。事实上，如果在修复一个 bug 时不小心引入另一个 bug 会是非常令人尴尬的。

我们在上次写的类里再增加两个测试，来更全面的测试这个方法：

# polls/tests.py

def test_was_published_recently_with_old_question(self):
    """
    对于pub_date超过1天的问题，was_published_recently（）返回False。
    """
    time = timezone.now() - datetime.timedelta(days=1, seconds=1)
    old_question = Question(pub_date=time)
    self.assertIs(old_question.was_published_recently(), False)

def test_was_published_recently_with_recent_question(self):
    """
    was_published_recently（）对于pub_date在最后一天内的问题返回True。
    """
    time = timezone.now() - datetime.timedelta(hours=23, minutes=59, seconds=59)
    recent_question = Question(pub_date=time)
    self.assertIs(recent_question.was_published_recently(), True)

现在，我们有三个测试来确保 Question.was_published_recently() 方法对于过去，最近，和将来的三种情况都返回正确的值。

再次申明，尽管 polls 现在是个非常简单的应用，但是无论它以后成长到多么复杂，要和其他代码进行怎样的交互，我们都能保证进行过测试的那些方法的行为永远是符合预期的。

 

测试视图

我们的投票应用对所有问题都一视同仁：它将会发布所有的问题，也包括那些 pub_date 字段值是未来的问题。

然而我们应该改善这一点。如果 pub_date 设置为未来某天，这应该被解释为这个问题将在所填写的时间点才被发布，而在之前是不可见的。

1. 针对视图的测试

为了修复上述 bug ，我们这次采用「测试驱动」的开发模式。我们通过模拟用户使用浏览器访问被测试的应用来检查代码行为是否符合预期。

在我们动手之前，先看看需要用到的工具们。

2. Django 测试工具之 Client

Django 提供了一个供测试使用的 Client 来模拟用户和视图层代码的交互。我们能在 tests.py 甚至是 shell 中使用它。

我们从 shell 开始，首先我们要做一些在 tests.py 里不是必须的准备工作。

首先是在 shell 中配置测试环境:

 python manage.py shell

>>> from django.test.utils import setup_test_environment
>>> setup_test_environment()

setup_test_environment() 提供了一个模板渲染器，允许我们为 responses 添加一些额外的属性，例如 response.context，

未安装此 app 无法使用此功能。注意，这个方法并不会配置测试数据库，所以接下来的代码将会在当前存在的数据库上运行，输出的内容可能由于数据库内容的不同而不同。

如果你的 settings.py 中关于 TIME_ZONE 的设置不对，你可能无法获取到期望的结果。如果你之前忘了设置，在继续之前检查一下。

然后在shell 中我们需要导入 Client 类（稍后在tests.py中我们将使用自带客户端的django.test.TestCase类，其中有Cluent类，因此不需要这个类）:

>>> from django.test import Client

# 创建一个客户端实例供我们使用
>>> client = Client()

搞定了之后，我们可以要求 client 为我们工作了:

>>> response = client.get('/')   # 从'/'获取一个响应对象
Not Found: /

'''我们应该期望从该地址获得404; 如果你看到“无效的HTTP_HOST标头”错误和400响应,
你可能省略了前面描述的setup_test_environment（）调用。'''
>>> response.status_code
404

'''另一方面，我们应该期待在'/ polls /'找到一些东西。
我们将使用'reverse（）'而不是硬编码的URL'''
>>> from django.urls import reverse
>>> response = client.get(reverse('polls:index'))
>>> response.status_code
200
>>> response.content
b'\n    <ul>\n    \n        <li><a href="/polls/1/">What&#39;s up?</a></li>\n    \n    </ul>\n\n'
>>> response.context['latest_question_list']
<QuerySet [<Question: What's up?>]>

 

3. 改善视图代码

现在的投票列表会显示将来的投票（ pub_date 值是未来的某天)。我们来修复这个问题。

在上篇博客里，我们介绍了基于 ListView 的视图类：

# polls/views.py

class IndexView(generic.ListView):
    template_name = 'polls/index.html'
    context_object_name = 'latest_question_list'

    def get_queryset(self):
        """返回最近发布的5个问题."""
        return Question.objects.order_by('-pub_date')[:5]

我们需要改进 get_queryset() 方法，让他它能通过将 Question 的 pub_data 属性与 timezone.now() 相比较来判断是否应该显示此 Question。上面get_queryset() 方法改成下面这样：

# polls/views.py

def get_queryset(self):
    """
    返回最近发布的五个问题（不包括那些问题
发表在未来）。
    """
    return Question.objects.filter(pub_date__lte=timezone.now())
        .order_by('-pub_date')[:5]

Question.objects.filter（pub_date__lte = timezone.now（））返回一个查询集，其中包含pub_date早于或等于 timezone.now。

4. 测试新视图

启动服务器、在浏览器中载入站点、创建一些发布时间在过去和将来的 Questions ，然后检验只有已经发布的Questions 会展示出来，现在你可以对自己感到满意了。你不想每次修改可能与这相关的代码时都重复这样做 —— 所以让我们基于以上shell 会话中的内容，再编写一个测试。

我们写一个公用的快捷函数用于创建投票问题，再为视图创建一个测试类,将下面的代码添加到 polls/tests.py ：

# polls/tests.py

from django.urls import reverse
def create_question(question_text, days):
    """
    使用给定的`question_text`创建一个问题，并发布给定数量的'days`到现在（对于过去发布的问题为负，对尚未发布的问题为正）。
    """
    time = timezone.now() + datetime.timedelta(days=days)
    return Question.objects.create(question_text=question_text, pub_date=time)


class QuestionIndexViewTests(TestCase):
    def test_no_questions(self):
        """
        如果不存在任何问题，则会显示相应的消息
        """
        response = self.client.get(reverse('polls:index'))
        self.assertEqual(response.status_code, 200)
        self.assertContains(response, "No polls are available.")
        self.assertQuerysetEqual(response.context['latest_question_list'], [])

    def test_past_question(self):
        """
        带有pub_date的过去发布的问题在索引页面显示。
        """
        create_question(question_text="Past question.", days=-30)
        response = self.client.get(reverse('polls:index'))
        self.assertQuerysetEqual(
            response.context['latest_question_list'],
            ['<Question: Past question.>']
        )

    def test_future_question(self):
        """
        带有pub_date的将来发布的问题不会在索引页面显示。
        """
        create_question(question_text="Future question.", days=30)
        response = self.client.get(reverse('polls:index'))
        self.assertContains(response, "No polls are available.")
        self.assertQuerysetEqual(response.context['latest_question_list'], [])

    def test_future_question_and_past_question(self):
        """
        即使存在过去已发布和将来要发布的问题，也只显示过去的问题。
        """
        create_question(question_text="Past question.", days=-30)
        create_question(question_text="Future question.", days=30)
        response = self.client.get(reverse('polls:index'))
        self.assertQuerysetEqual(
            response.context['latest_question_list'],
            ['<Question: Past question.>']
        )

    def test_two_past_questions(self):
        """
        问题索引页面可能会显示多个问题。

        """
        create_question(question_text="Past question 1.", days=-30)
        create_question(question_text="Past question 2.", days=-5)
        response = self.client.get(reverse('polls:index'))
        self.assertQuerysetEqual(
            response.context['latest_question_list'],
            ['<Question: Past question 2.>', '<Question: Past question 1.>']
        )

让我们来更详细地解释以上这些内容：

• 首先是一个快捷函数 create_question，它封装了创建投票的流程，减少了重复代码。
• test_no_questions 方法里没有创建任何投票，它检查返回的网页上有没有 "No polls are available." 这段消息和 latest_question_list 是否为空。注意到 django.test.TestCase类提供了一些额外的 assertion 方法，在这个例子中，我们使用了 assertNotContains（） 和 assertQuerysetEqual（） 。
• 在 test_past_question 方法中，我们创建了一个投票并检查它是否出现在列表中。
• 在 test_future_question 方法中，我们创建 pub_date 在未来某天的投票。

数据库会在每次调用测试方法前被重置，所以第一个投票已经没了，所以主页中应该没有任何投票。

实际上，测试就是假装一些管理员的输入，然后通过用户端的表现是否符合预期来判断新加入的改变是否破坏了原有的系统状态。

5. 测试 DetailView

我们的工作似乎已经很完美了？

不，还有一个问题：就算在发布日期时未来的那些投票不会在目录页 index 里出现，但是如果用户知道或者猜到正确的 URL ，还是可以访问到它们。

所以我们得在 DetailView 里增加一些约束：

# polls/views.py

class DetailView(generic.DetailView):
    ...
    def get_queryset(self):
        """
        排除尚未发布的任何问题。
        """
        return Question.objects.filter(pub_date__lte=timezone.now())

当然，我们将增加一些测试来检验 pub_date 在过去的 Question 可以显示出来，而 pub_date 在未来的不可以：

# polls/tests.py

class QuestionDetailViewTests(TestCase):
    def test_future_question(self):
        """
        pub_date为将来发布的问题的详细信息视图将返回404未找到的内容。
        """
        future_question = create_question(question_text='Future question.', days=5)
        url = reverse('polls:detail', args=(future_question.id,))
        response = self.client.get(url)
        self.assertEqual(response.status_code, 404)

    def test_past_question(self):
        """
        pub_date为过去发布的问题的详细信息视图将displays the question's text。
        """
        past_question = create_question(question_text='Past Question.', days=-5)
        url = reverse('polls:detail', args=(past_question.id,))
        response = self.client.get(url)
        self.assertContains(response, past_question.question_text)

 

6. 更多的测试思路

• 我们应该给 ResultsView 也增加一个类似的 get_queryset 方法，并且为它创建测试。这和我们之前干的差不多，事实上，基本就是重复一遍。
• 我们还可以从各个方面改进投票应用，但是测试会一直伴随我们。比方说，在目录页上显示一个没有选项 Choices 的投票问题就没什么意义。我们可以检查并排除这样的投票题。
• 测试可以创建一个没有选项的投票，然后检查它是否被显示在目录上。当然也要创建一个有选项的投票，然后确认它确实被显示了。
• 恩，也许你想让管理员能在目录上看见未被发布的那些投票，但是普通用户看不到。不管怎么说，如果你想要增加一个新功能，那么同时一定要为它编写测试。不过你是先写代码还是先写测试那就随你了。
• 在未来的某个时刻，你一定会去查看测试代码，然后开始怀疑：「这么多的测试不会使代码越来越复杂吗？」。别着急，我们马上就会谈到这一点。

 

当需要测试的时候，测试用例越多越好

• 貌似我们的测试多的快要失去控制了。按照这样发展下去，测试代码就要变得比应用的实际代码还要多了。而且测试代码大多都是重复且不优雅的，特别是在和业务代码比起来的时候，这种感觉更加明显。
• 但是这没关系！ 就让测试代码继续肆意增长吧。大部分情况下，你写完一个测试之后就可以忘掉它了。在你继续开发的过程中，它会一直默默无闻地为你做贡献的。
• 但有时测试也需要更新。想象一下如果我们修改了视图，只显示有选项的那些投票，那么只前写的很多测试就都会失败。但这也明确地告诉了我们哪些测试需要被更新，所以测试也会测试自己。
• 最坏的情况是，当你继续开发的时候，发现之前的一些测试现在看来是多余的。但是这也不是什么问题，多做些测试也 不错。

如果你对测试有个整体规划，那么它们就几乎不会变得混乱。下面有几条好的建议：

• 对于每个模型和视图都建立单独的 TestClass
• 每个测试方法只测试一个功能
• 给每个测试方法起个能描述其功能的名字

 

深入代码测试

在本博客中，我们仅仅是了解了测试的基础知识。

举个例子，在上述的测试中，我们已经从代码逻辑和视图响应的角度检查了应用的输出，现在你可以从一个更加 "in-browser" 的角度来检查最终渲染出的 HTML 是否符合预期，使用 Selenium 可以很轻松的完成这件事。这个工具不仅可以测试 Django 框架里的代码，还可以检查其他部分，比如说你的 JavaScript。它假装成是一个正在和你站点进行交互的浏览器，就好像有个真人在访问网站一样！Django 它提供了 LiveServerTestCase 来和 Selenium 这样的工具进行交互。

如果你在开发一个很复杂的应用的话，你也许想在每次提交代码时自动运行测试，也就是我们所说的持续集成 continuous integration ，这样就能实现质量控制的自动化，起码是部分自动化。

一个找出代码中未被测试部分的方法是检查代码覆盖率。它有助于找出代码中的薄弱部分和无用部分。如果你无法测试一段代码，通常说明这段代码需要被重构或者删除。

 

当你已经比较熟悉测试 Django 视图的方法后，我们就可以开始下一篇博客——学习静态文件管理的相关知识

 

写在最后，欢迎关注一个一起学python的微信公众号：大众学python

掏出手机扫一扫：