自动化测试

测试代码，是用来检查代码能否正常运行的程序。

测试在不同的层次中都存在。有些测试只关注某个很小的细节（某个模型的某个方法的返回值是否满足预期？），而另一些测试可能检查对某个软件的一系列操作（某一用户输入序列是否造成了预期的结果？）。

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

测试不仅能发现错误，而且能预防错误

如果没有测试，整个应用的行为意图会变得更加的不清晰。甚至当在看自己写的代码时也是这样，有时候需要仔细研读一段代码才能搞清楚它有什么用。

而测试的出现改变了这种情况。测试就好像是从内部仔细检查你的代码，当有些地方出错时，这些地方将会变得很显眼——就算自己没有意识到那里写错了。

基础测试策略

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

一些开发者遵循 "测试驱动" 的开发原则，在写代码之前先写测试。这种方法看起来有点反直觉，但事实上，这和大多数人日常的做法是相吻合的。会先描述一个问题，然后写代码来解决它。「测试驱动」的开发方法只是将问题的描述抽象为了 Python 的测试样例。

更普遍的情况是，一个刚接触自动化测试的新手更倾向于先写代码，然后再写测试。虽然提前写测试可能更好，但是晚点写起码也比没有强。

有时候很难决定从哪里开始下手写测试。如果才写了几千行 Python 代码，选择从哪里开始写测试确实不怎么简单。如果是这种情况，那么在下次修改代码（比如加新功能，或者修复 Bug）之前写个测试是比较合理且有效的。

写测试代码

首先得有个 Bug

在 polls 应用现在就有一个小 bug 需要被修复：如果 Question 是在一天之内发布的， Question.was_published_recently() 方法将会返回 True ，然而现在这个方法在 Question 的 pub_date 字段比当前时间还晚时也会返回 True（这是个 Bug）。

用djadmin:`shell`命令确认一下这个方法的日期bug。运行：

python manage.py shell

>>> import datetime
>>> from django.utils import timezone
>>> from polls.models import Question
>>> # create a Question instance with pub_date 30 days in the future
>>> future_question = Question(pub_date=timezone.now() + datetime.timedelta(days=30))
>>> # was it published recently?
>>> future_question.was_published_recently()
True

因为将来发生的是肯定不是最近发生的，所以代码明显是错误的。

然后需要编写测试代码，来发现这个bug。按照惯例，Django 应用的测试应该写在应用的 tests.py 文件里。测试系统会自动的在所有以 tests 开头的文件里寻找并执行测试代码。

将下面的代码写入 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() returns False for questions whose pub_date
        is in the future.
        """
        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。

运行测试

输入以下代码运行测试:

 python manage.py test polls

会看到如下图所示的运行结果:

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

• 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。

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

修复bug

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

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

这次测试代码就通过了。

更全面的测试

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

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

def test_was_published_recently_with_old_question(self):
    """
    was_published_recently() returns False for questions whose pub_date
    is older than 1 day.
    """
    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() returns True for questions whose pub_date
    is within the last day.
    """
    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 设置为未来某天，这应该被解释为这个问题将在所填写的时间点才被发布，而在之前是不可见的。

为了修复上述 bug ，先要编写测试，然后再去改代码。事实上，这是一个「测试驱动」开发模式的实例，但其实这两者的顺序不太重要。

在上面的测试中，关注代码的内部行为。通过模拟用户使用浏览器访问被测试的应用来检查代码行为是否符合预期。

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

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() 安装了一个模板渲染器，这能够检查响应上的一些额外属性，如 response.context，否则将无法使用此功能。请注意，这个方法 不会建立一个测试数据库，所以下面的内容将针对现有的数据库运行，输出结果可能略有不同，这取决于已经创建了哪些问题。如果在 settings.py 中的 TIME_ZONE 不正确，可能会得到意外的结果。如果不记得之前的配置，请在继续之前检查。

然后需要导入 django.test.TestCase 类:

>>> from django.test import Client
>>> # create an instance of the client for our use
>>> client = Client()

然后，可以使用 client 进行测试了:

>>> # get a response from '/'
>>> response = client.get('/')
Not Found: /
>>> # we should expect a 404 from that address; if you instead see an
>>> # "Invalid HTTP_HOST header" error and a 400 response, you probably
>>> # omitted the setup_test_environment() call described earlier.
>>> response.status_code
404
>>> # on the other hand we should expect to find something at '/polls/'
>>> # we'll use 'reverse()' rather than a hardcoded 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's up?</a></li>\n    \n    </ul>\n\n'
>>> response.context['latest_question_list']
<QuerySet [<Question: What's up?>]>

改善视图代码

现在的投票列表会显示将来的投票（ 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):
        """Return the last five published questions."""
        return Question.objects.order_by('-pub_date')[:5]

需要改进 get_queryset() 方法，让它能通过将 Question 的 pub_data 属性与 timezone.now() 相比较来判断是否应该显示此 Question。首先需要一行 import 语句：

from django.utils import timezone

然后把 get_queryset 方法改写成下面这样：

def get_queryset(self):
    """
    Return the last five published questions (not including those set to be
    published in the future).
    """
    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 的问题。

测试新视图

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

from django.urls import reverse

然后写一个公用的快捷函数用于创建投票问题，再为视图创建一个测试类：

def create_question(question_text, days):
    """
    Create a question with the given `question_text` and published the
    given number of `days` offset to now (negative for questions published
    in the past, positive for questions that have yet to be published).
    """
    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):
        """
        If no questions exist, an appropriate message is displayed.
        """
        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):
        """
        Questions with a pub_date in the past are displayed on the
        index page.
        """
        question = create_question(question_text="Past question.", days=-30)
        response = self.client.get(reverse('polls:index'))
        self.assertQuerysetEqual(
            response.context['latest_question_list'],
            [question],
        )

    def test_future_question(self):
        """
        Questions with a pub_date in the future aren't displayed on
        the index page.
        """
        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):
        """
        Even if both past and future questions exist, only past questions
        are displayed.
        """
        question = 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],
        )

    def test_two_past_questions(self):
        """
        The questions index page may display multiple questions.
        """
        question1 = create_question(question_text="Past question 1.", days=-30)
        question2 = create_question(question_text="Past question 2.", days=-5)
        response = self.client.get(reverse('polls:index'))
        self.assertQuerysetEqual(
            response.context['latest_question_list'],
            [question2, question1],
        )

首先是一个快捷函数 create_question，它封装了创建投票的流程，减少了重复代码。

test_no_questions 方法里没有创建任何投票，它检查返回的网页上有没有 "No polls are available." 这段消息和 latest_question_list 是否为空。注意到 django.test.TestCase 类提供了一些额外的 assertion 方法，在这个例子中，我们使用了 assertContains() 和 assertQuerysetEqual() 。

在 test_past_question 方法中，我们创建了一个投票并检查它是否出现在列表中。

在 test_future_question 中，我们创建 pub_date 在未来某天的投票。数据库会在每次调用测试方法前被重置，所以第一个投票已经没了，所以主页中应该没有任何投票。

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

测试DetailView

就算在发布日期时未来的那些投票不会在目录页 index 里出现，但是如果用户知道或者猜到正确的 URL ，还是可以访问到它们。所以得在 DetailView 里增加一些约束，修改polls/views.py：

class DetailView(generic.DetailView):
    ...
    def get_queryset(self):
        """
        Excludes any questions that aren't published yet.
        """
        return Question.objects.filter(pub_date__lte=timezone.now())

增加一些测试来检验 pub_date 在过去的 Question 能够被显示出来，而 pub_date 在未来的则不可以：

class QuestionDetailViewTests(TestCase):
    def test_future_question(self):
        """
        The detail view of a question with a pub_date in the future
        returns a 404 not found.
        """
        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):
        """
        The detail view of a question with a pub_date in the past
        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)

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

大部分情况下，你写完一个测试之后就可以忘掉它了。在继续开发的过程中，它会一直默默无闻地做贡献的。

但有时测试也需要更新。想象一下如果修改了视图，只显示有选项的那些投票，那么只前写的很多测试就都会失败。但这也明确地告诉了哪些测试需要被更新，所以测试也会测试自己。

最坏的情况是，当继续开发的时候，发现之前的一些测试现在看来是多余的。但是这也不是什么问题，多做些测试也 不错。

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

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

深入代码测试

这里仅仅是了解了测试的基础知识。能做的还有很多，而且世界上有很多有用的工具来帮助完成这些有意义的事。

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

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

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