21.3　调整功能测试，以便通过POP3测试真实的电子邮件

啊，确实应该如此。功能测试现在在真实的服务器中运行，而不是使用 LiveServerTestCase，因此我们不能再检查本地的 django.mail.outbox 中有没有发出的邮件了。

首先，在功能测试中要想办法判断是不是运行在过渡服务器中。在 base.py 中，把 staging_server 变量绑定到 self 上：

functional_tests/base.py (ch18l009)

    def setUp(self):
        self.browser = webdriver.Firefox()
        self.staging_server = os.environ.get('STAGING_SERVER')
        if self.staging_server:
           self.live_server_url = 'http://' + self.staging_server

然后，构建一个辅助函数，使用 Python 标准库中极其难用的 POP3 客户端从真实的 POP3 电子邮件服务器中获取真实的电子邮件：

functional_tests/test_login.py (ch18l010)

import os
import poplib
import re
import time
[...]
    def wait_for_email(self, test_email, subject):
        if not self.staging_server:
            email = mail.outbox[0]
            self.assertIn(test_email, email.to)
            self.assertEqual(email.subject, subject)
            return email.body
        email_id = None
        start = time.time()
        inbox = poplib.POP3_SSL('pop.mail.yahoo.com')
        try:
            inbox.user(test_email)
            inbox.pass_(os.environ['YAHOO_PASSWORD'])
            while time.time() - start < 60:
                # 获取最新的10封邮件
                count,  = inbox.stat()
                for i in reversed(range(max(1, count - 10), count + 1)):
                    print('getting msg', i)
                    , lines, __ = inbox.retr(i)
                    lines = [l.decode('utf8') for l in lines]
                    print(lines)
                    if f'Subject: {subject}' in lines:
                        email_id = i
                        body = '\n'.join(lines)
                        return body
                time.sleep(5)
        finally:
            if email_id:
                inbox.dele(email_id)
            inbox.quit()

　测试时我使用的是 Yahoo 账户，你可以使用任何电子邮件服务，只要支持通过 POP3 访问即可。你要在运行功能测试的控制台中设定 YAHOO_PASSWORD 环境变量。

接下来调整功能测试中其他需要改动的地方。首先，针对本地环境和过渡服务器为 test_email 变量设定不同的值：

functional_tests/test_login.py (ch18l011-1)

@@ -7,7 +7,7 @@ from selenium.webdriver.common.keys import Keys
 from .base import FunctionalTest
-TEST_EMAIL = 'edith@example.com'
+
 SUBJECT = 'Your login link for Superlists'
@@ -33,7 +33,6 @@ class LoginTest(FunctionalTest):
                     print('getting msg', i)
                     , lines,  = inbox.retr(i)
                     lines = [l.decode('utf8') for l in lines]
-                    print(lines)
                     if f'Subject: {subject}' in lines:
                         emailid = i
                         body = '\n'.join(lines)
@@ -49,6 +48,11 @@ class LoginTest(FunctionalTest):
         # 伊迪丝访问这个很棒的超级列表网站
         # 第一次注意到导航栏中有“登录”区域
         # 看到要求输入电子邮件地址，她便输入了
+        if self.staging_server:
+            test_email = 'edith.testuser@yahoo.com'
+        else:
+            test_email = 'edith@example.com'
+
         self.browser.get(self.live_server_url)

然后使用那个变量，并调用新定义的辅助函数：

functional_tests/test_login.py (ch18l011-2)

@@ -54,7 +54,7 @@ class LoginTest(FunctionalTest):
             test_email = 'edith@example.com'
         self.browser.get(self.live_server_url)
-        self.browser.find_element_by_name('email').send_keys(TEST_EMAIL)
+        self.browser.find_element_by_name('email').send_keys(test_email)
         self.browser.find_element_by_name('email').send_keys(Keys.ENTER)
         # 出现一个消息，告诉她邮件已经发出
@@ -64,15 +64,13 @@ class LoginTest(FunctionalTest):
         ))
         # 她查看邮件，看到一个消息
-        email = mail.outbox[0]
-        self.assertIn(TEST_EMAIL, email.to)
-        self.assertEqual(email.subject, SUBJECT)
+        body = self.wait_for_email(test_email, SUBJECT)
         # 邮件中有个URL链接
-        self.assertIn('Use this link to log in', email.body)
-        url_search = re.search(r'http://.+/.+$', email.body)
+        self.assertIn('Use this link to log in', body)
+        url_search = re.search(r'http://.+/.+$', body)
         if not url_search:
-            self.fail(f'Could not find url in email body:\n{email.body}')
+            self.fail(f'Could not find url in email body:\n{body}')
         url = url_search.group(0)
         self.assertIn(self.live_server_url, url)
@@ -80,11 +78,11 @@ class LoginTest(FunctionalTest):
         self.browser.get(url)
         # 她登录了！
-        self.wait_to_beloggedin(email=TEST_EMAIL)
+        self.wait_to_beloggedin(email=test_email)
         # 现在她要退出
         self.browser.find_element_by_link_text('Log out').click()
         # 她退出了
-        self.wait_to_beloggedout(email=TEST_EMAIL)
+        self.wait_to_beloggedout(email=test_email)

不管你信不信，这样改动之后就行了。经功能测试确认，登录功能可以正常使用了——我们可是发送了真实的电子邮件啊！

　我费了好大劲才凑出了检查电子邮件的代码，目前还不雅观，有点脆弱（常见的问题是错误沿用上一次测试的电子邮件）。如果能整理一下，再多试试，我想代码会更可靠。如果不想这么麻烦，可以使用 mailinator.com 这样的服务，只需少量费用就能获得一个一次性的电子邮件地址和查看邮件的 API。

21.4　在过渡服务器中管理测试数据库

现在可以再次运行功能测试，此时又会看到一个失败测试，因为无法创建已经通过认证的会话，所以针对“My Lists”页面的测试失败了：

$ STAGING_SERVER=superlists-staging.ottg.eu python manage.py test functional_tests
 
ERROR: testloggedin_users_lists_are_saved_as_my_lists
(functional_tests.test_my_lists.MyListsTest)
[...]
selenium.common.exceptions.TimeoutException: Message: Could not find element
with id id_logout. Page text was:
Superlists
Sign in
Start a new To-Do list
 
Ran 8 tests in 72.742s
 
FAILED (errors=1)

失败的真正原因是 create_pre_authenticated_session 函数只能操作本地数据库。我们要找到一种方法，管理服务器中的数据库。

21.4.1　创建会话的Django管理命令

若想在服务器中操作，就要编写一个自成一体的脚本，在服务器中的命令行里运行。大多数情况下都会使用 Fabric 执行这样的脚本。

尝试编写可在 Django 环境中运行的独立脚本（和数据库交互等），有些问题要谨慎处理，例如正确设定 DJANGO_SETTINGS_MODULE 环境变量，还要正确处理 sys.path。

我们可不想在这些细节上浪费时间。其实 Django 允许我们自己创建“管理命令”（可以使用 python manage.py 运行的命令），可以把一切琐碎的事情都交给 Django 完成。管理命令保存在应用的 management/commands 文件夹中：

$ mkdir -p functional_tests/management/commands
$ touch functional_tests/management/__init__.py
$ touch functional_tests/management/commands/__init__.py

管理命令的样板代码是一个类，继承自 django.core.management.BaseCommand，而且定义了一个名为 handle 的方法：

functional_tests/management/commands/create_session.py

from django.conf import settings
from django.contrib.auth import BACKEND_SESSION_KEY, SESSION_KEY, get_user_model
User = get_user_model()
from django.contrib.sessions.backends.db import SessionStore
from django.core.management.base import BaseCommand
class Command(BaseCommand):
    def add_arguments(self, parser):
        parser.add_argument('email')
    def handle(self, args, *options):
        session_key = create_pre_authenticated_session(options['email'])
        self.stdout.write(session_key)
def create_pre_authenticated_session(email):
    user = User.objects.create(email=email)
    session = SessionStore()
    session[SESSION_KEY] = user.pk
    session[BACKEND_SESSION_KEY] = settings.AUTHENTICATION_BACKENDS[0]
    session.save()
    return session.session_key

create_pre_authenticated_session 函数的代码从 test_my_lists.py 文件中提取而来。handle 方法从选项中获取电子邮件地址，返回一个将要存入浏览器 cookie 中的会话键。这个管理命令还会把会话键打印到命令行中。试一下这个命令：

$ python manage.py create_session a@b.com
Unknown command: 'create_session'

还要做一步设置——把 functional_tests 加入 settings.py，让 Django 把它识别为一个可能包含管理命令和测试的真正应用：

superlists/settings.py

+++ bsuperlistssettings.py
@@ -42,6 +42,7 @@ INSTALLED_APPS = [
     'lists',
     'accounts',
+    'functional_tests',
 ]

现在这个管理命令可以使用了：

$ python manage.py create_session a@b.com
qnslckvp2aga7tm6xuivyb0ob1akzzwl

　如果报错说缺少 auth_user 表，可能就要执行 manage.py migrate 命令。如果还不行，重新来过，删除 db.sqlite3，再执行 migrate 命令。

21.4.2　让功能测试在服务器上运行管理命令

接下来调整 test_my_lists.py 文件中的测试，让它在本地服务器中运行本地函数，但是在过渡服务器中运行管理命令：

functional_tests/test_my_lists.py (ch18l016)

from django.conf import settings
from .base import FunctionalTest
from .server_tools import create_session_on_server
from .management.commands.create_session import create_pre_authenticated_session
class MyListsTest(FunctionalTest):
    def create_pre_authenticated_session(self, email):
        if self.staging_server:
            session_key = create_session_on_server(self.staging_server, email)
        else:
            session_key = create_pre_authenticated_session(email)
        ## 为了设定cookie，我们要先访问网站
        ## 而404页面是加载最快的
        self.browser.get(self.live_server_url + "404_no_such_url")
        self.browser.add_cookie(dict(
            name=settings.SESSION_COOKIE_NAME,
            value=session_key,
            path='/',
        ))
    [...]

此外，还要调整 base.py，当处在过渡服务器中时，提供更多信息：

functional_tests/base.py (ch18l017)

from .server_tools import reset_database  ➊
[...]
class FunctionalTest(StaticLiveServerTestCase):
    def setUp(self):
        self.browser = webdriver.Firefox()
        self.staging_server = os.environ.get('STAGING_SERVER')
        if self.staging_server:
            self.live_server_url = 'http://' + self.staging_server
            reset_database(self.staging_server)  ➊

➊ 这个函数的作用是在两次测试之间还原服务器中的数据库。稍后我会讲解创建会话这段代码的逻辑，以及为什么可以这么做。

21.4.3　直接在Python代码中使用Fabric

除了 fab 命令之外，Fabric 还提供了 API，这样便可以直接在 Python 代码中执行 Fabric 服务器命令。为此，只需通过一个字符串告诉 Fabric 你想连接的主机即可：

functional_tests/server_tools.py

from fabric.api import run
from fabric.context_managers import settings
def getmanage_dot_py(host):
    return f'~/sites/{host}/virtualenvbinpython ~/sites/{host}/source/manage.py'
def reset_database(host):
    manage_dot_py = getmanage_dot_py(host)
    with settings(host_string=f'elspeth@{host}'):  ➊
        run(f'{manage_dot_py} flush --noinput')  ➋
def create_session_on_server(host, email):
    manage_dot_py = getmanage_dot_py(host)
    with settings(host_string=f'elspeth@{host}'):  ➊
        session_key = run(f'{manage_dot_py} create_session {email}')  ➋
        return session_key.strip()

❶ 这个上下文管理器设定主机字符串，格式为 user@server-address（我直接把自己的服务器用户名 elspeth 写进去了，别忘了修改）。

❷ 在上下文中可以像在 fabfile 中那样直接调用 Fabric 命令。

21.4.4　回顾：在本地服务器和过渡服务器中创建会话的方式

充分理解了吗？下面通过 ASCII 图表回顾一下：

• 在本地

+-----------------------------------+      +-------------------------------------+
| MyListsTest                       | -->  | .management.commands.create_session |
| .create_pre_authenticated_session |      |  .create_pre_authenticated_session  |
|           (locally)               |      |        (locally)                    |
+-----------------------------------+      +-------------------------------------+

• 在过渡服务器中

+-----------------------------------+      +-------------------------------------+
| MyListsTest                       |      | .management.commands.create_session |
| .create_pre_authenticated_session |      |  .create_pre_authenticated_session  |
|            (locally)              |      |           (on server)               |
+-----------------------------------+      +-------------------------------------+
            |                                                ^
            v                                                |
+----------------------------+     +--------+     +------------------------------+
| server_tools               | --> | fabric | --> | ./manage.py create_session   |
| .create_session_on_server  |     | "run"  |     |       (on server)            |
|        (locally)           |     +--------+     +------------------------------+
+----------------------------+

不论如何，看一下这么做是否可行。首先，在本地运行测试，确认没有造成任何破坏：

$ python manage.py test functional_tests.test_my_lists
[...]
OK

然后在服务器中运行。先把代码推送到服务器中：

$ git push # 要先提交改动
$ cd deploy_tools
$ fab deploy --host=superlists-staging.ottg.eu

再运行测试：

$ STAGING_SERVER=superlists-staging.ottg.eu python manage.py test \
 functional_tests.test_my_lists
[...]
[superlists-staging.ottg.eu] Executing task 'reset_database'
~/sites/superlists-staging.ottg.eu/source/manage.py flush --noinput
[superlists-staging.ottg.eu] out: Syncing...
[superlists-staging.ottg.eu] out: Creating tables ...
[...]
.
 ---------------------------------------------------------------------
Ran 1 test in 25.701s
 
OK

看起来没问题。还可以运行全部测试确认一下：

$ STAGING_SERVER=superlists-staging.ottg.eu python manage.py test \
 functional_tests
[...]
[superlists-staging.ottg.eu] Executing task 'reset_database'
[...]
Ran 8 tests in 89.494s
 
OK

太棒了！

　我展示了管理测试数据库的一种方法，你也可以试验其他方式。例如，使用 MySQL 或 Postgres，可以打开一个 SSH 隧道连接服务器，使用端口转发直接操作数据库。然后修改 settings.DATABASES，让功能测试使用隧道连接的端口和数据库交互。

警告：小心，不要在线上服务器中运行测试

我们现在遇到一件危险的事，因为编写的代码能直接影响服务器中的数据库。一定要非常非常小心，别在错误的主机中运行功能测试，把生产数据库清空了。

此时，可以考虑使用一些安全防护措施。例如，把过渡环境和生产环境放在不同的服务器中，而且不同的服务器使用不同的口令认证密钥对。

在生产环境的数据副本中运行测试也有同样的危险，我就曾经不小心重复给客户发送了发票（见附录D）。这是前车之鉴啊。

21.5　集成日志相关的代码

结束本章之前，我们要把日志相关的代码集成到应用中。把输出日志的代码放在那儿，并且纳入版本控制，有助于调试以后遇到的登录问题。毕竟有些人不怀好意。

先把 Gunicorn 的配置保存到 deploy_tools 文件夹里的临时文件中：

deploy_tools/gunicorn-systemd.template.service (ch18l020)

[...]
Environment=EMAIL_PASSWORD=SEKRIT
ExecStart=homeelspeth/sites/SITENAME/virtualenvbingunicorn \
    --bind unix:tmpSITENAME.socket \
    --access-logfile ../access.log \
    --error-logfile ../error.log \
    superlists.wsgi:application
[...]

然后在配置笔记中加上几点，提醒自己别忘了在 Gunicorn 配置文件中设定电子邮件密码的环境变量：

deploy_tools/provisioning_notes.md (ch18l021)

## Systemd服务
 参见gunicorn-systemd.template.service
 把SITENAME替换成具体的域名，例如staging.my-domain.com
* 把SEKRIT替换成电子邮件密码
[...]

21.6　小结

在服务器中运行新代码总会让一些缺陷和意料之外的问题显露出来。为了解决这些问题，我们做了很多工作，不过在这个过程中也收获颇多。

我们定义了通用的 wait 装饰器，这更符合 Python 习惯，在功能测试中到处都可以使用。我们让测试固件既可以在本地使用，也能在服务器中使用（包括对“真实”电子邮件的测试）。此外，还设定了更牢靠的日志配置。

不过，在部署线上网站之前，最好为用户提供他们真正想要的功能——下一章介绍如何在“My Lists”页面中汇总用户的清单。

在过渡服务器中捕获缺陷时学到的知识

• 固件也要在远程服务器中使用

  在本地运行测试，使用 LiveServerTestCase 即可以轻松通过 Django ORM 与测试数据库交互。与过渡服务器中的数据库交互就没这么简单了。解决方法之一是使用 Django 管理命令，如前文所示。不过也可以小心探索，找到适合自己的方法。

• 在服务器中重置数据时要格外小心

  能远程清除服务器中整个数据库的命令极其危险，一定要小心再小心，确保不会意外损坏生产数据。

• 日志对调试服务器中的问题非常重要

  你至少要能看到服务器产生的错误消息。对较为棘手的缺陷来说，还要能得到临时的“调试输出”，保存在某个文件中。

第 22 章　完成“My Lists”页面：由外而内的TDD

本章我要介绍一种技术，叫“由外而内”的 TDD。一直以来，我们几乎都在使用这种技术。“双循环”TDD 流程就体现了由外而内的思想——先编写功能测试，然后再编写单元测试，其实就是从外部设计系统，再分层编写代码。现在我要明确提出这个概念，再讨论其中涉及的常见问题。

22.1　对立技术：“由内而外”

“由外而内”的对立技术是“由内而外”，接触 TDD 之前，大多数人都凭直觉选择后者。提出一个设计想法之后，有时会自然而然地从最内部、最低层的组件开始实现。

例如，就我们现在面临的问题而言，要想为用户提供一个“My Lists”页面显示已经保存的清单，我们首先会迫不及待地在 List 模型中添加 owner 属性，因为根据需求推断，显然需要这样一个属性。之后，借助这个新属性修改外层代码，例如视图和模板，最后添加 URL 路由，指向新视图。

这么做感觉更自然，因为所用的代码从来不会依赖尚未实现的功能。内层的一切都是构建外层的坚实基础。

不过，像这样由内而外的工作方式也有缺点。

22.2　为什么选择使用“由外而内”

由内而外的技术最明显的问题是它迫使我们抛开 TDD 流程。功能测试第一次失败可能是因为缺少 URL 路由，但我们决定忽略这一点，先为数据库模型对象添加属性。

我们可能已经在脑海中构思好了内层的模样，而且这些想法往往都很好，不过这些都是对真实需求的推测，因为还未构造使用内层组件的外层组件。

这么做可能会导致内层组件太笼统，或者比真实需求功能更强——不仅浪费了时间，还把项目变得更为复杂。另一种常见的问题是，创建内层组件使用的 API 乍看起来对内部设计而言很合适，但之后会发现并不适用于外层组件。更糟的是，最后你可能会发现内层组件完全无法解决外层组件需要解决的问题。

与此相反，使用由外而内的工作方式，可以在外层组件的基础上构思想从内层组件获取的最佳 API。下面以实例说明如何使用由外而内技术。

22.3　“My Lists”页面的功能测试

编写下面这个功能测试时，我们从能接触到的最外层开始（表现层），然后是视图函数（或叫“控制器”），最后是最内层，在这个例子中是模型代码。

既然 create_pre_authenticated_session 函数可以正常使用，那么就可以直接用来编写针对“My Lists”页面的功能测试：

functional_tests/test_my_lists.py (ch19l001-1)

    def testloggedin_users_lists_are_saved_as_my_lists(self):
        # 伊迪丝是已登录用户
        self.create_pre_authenticated_session('edith@example.com')
        # 她访问首页，新建一个清单
        self.browser.get(self.live_server_url)
        self.add_list_item('Reticulate splines')
        self.add_list_item('Immanentize eschaton')
        first_list_url = self.browser.current_url
        # 她第一次看到My Lists链接
        self.browser.find_element_by_link_text('My lists').click()
        # 她看到这个页面中有她创建的清单
        # 而且清单根据第一个待办事项命名
        self.wait_for(
            lambda: self.browser.find_element_by_link_text('Reticulate splines')
        )
        self.browser.find_element_by_link_text('Reticulate splines').click()
        self.wait_for(
            lambda: self.assertEqual(self.browser.current_url, first_list_url)
        )

先创建一个包含几个待办事项的清单，然后检查这个列表会出现在新的“My Lists”页面上，而且以清单中的第一个待办事项命名。

接着前面的单元测试，再创建一个清单，确保的确会出现在“My Lists”页面上。与此同时，再检查只有已登录的用户才能看到“My Lists”页面：

functional_tests/test_my_lists.py (ch19l001-2)

    [...]
    self.wait_for(
        lambda: self.assertEqual(self.browser.current_url, first_list_url)
    )
    # 她决定再建一个清单试试
    self.browser.get(self.live_server_url)
    self.add_list_item('Click cows')
    second_list_url = self.browser.current_url
    # 在“My Lists”页面，这个新建的清单也显示出来了
    self.browser.find_element_by_link_text('My lists').click()
    self.wait_for(
        lambda: self.browser.find_element_by_link_text('Click cows')
    )
    self.browser.find_element_by_link_text('Click cows').click()
    self.wait_for(
        lambda: self.assertEqual(self.browser.current_url, second_list_url)
    )
    # 她退出后，“My Lists”链接不见了
    self.browser.find_element_by_link_text('Log out').click()
    self.wait_for(lambda: self.assertEqual(
        self.browser.find_elements_by_link_text('My lists'),
        []
    ))

上述功能测试使用了一个新的辅助方法，即 add_list_item，它抽象了在正确的输入框中输入文本的操作。这个辅助方法在 base.py 中定义：

functional_tests/base.py (ch19l001-3)

from selenium.webdriver.common.keys import Keys
[...]
    def add_list_item(self, item_text):
        num_rows = len(self.browser.find_elements_by_css_selector('#id_list_table tr'))
        self.get_item_input_box().send_keys(item_text)
        self.get_item_input_box().send_keys(Keys.ENTER)
        item_number = num_rows + 1
        self.wait_for_row_in_list_table(f'{item_number}: {item_text}')

定义好这个辅助方法之后，可以在其他功能测试中像下面这样使用：

functional_tests/test_list_item_validation.py

    self.add_list_item('Buy wellies')

我觉得使用这个辅助方法之后，功能测试的可读性提高了不少。我改了 6 处，看看你是否与我一样。

运行全部功能测试，做个提交，然后回到我们正在处理的这个功能测试。你看到的第一个错误应该是这样的：

$ python3 manage.py test functional_tests.test_my_lists
[...]
selenium.common.exceptions.NoSuchElementException: Message: Unable to locate
element: My lists

22.4　外层：表现层和模板

目前，这个测试失败，报错无法找到“My　Lists”链接。这个问题可以在表现层，即 base.html 模板里的导航条中解决。最少量的代码改动如下所示：

lists/templates/base.html (ch19l002-1)

    {% if user.email %}
      <ul class="nav navbar-nav navbar-left">
        <li><a href="#">My lists</a></li>
      </ul>
      <ul class="nav navbar-nav navbar-right">
        <li class="navbar-text">Logged in as {{ user.email }}</li>
        <li><a href="{% url 'logout' %}">Log out</a></li>
      </ul>

显然，这个链接没指向任何页面，不过却能解决这个问题，得到下一个失败消息：

$ python3 manage.py test functional_tests.test_my_lists
[...]
    lambda: self.browser.find_element_by_link_text('Reticulate splines')
[...]
selenium.common.exceptions.NoSuchElementException: Message: Unable to locate
element: Reticulate splines

失败消息指出要构建一个页面，用标题列出一个用户的所有清单。先从简单的开始——一个 URL 和一个占位模板。

可以再次使用由外而内技术，先从表现层开始，只写上地址，其他什么都不做：

lists/templates/base.html (ch19l002-2)

    <ul class="nav navbar-nav navbar-left">
      <li><a href="{% url 'my_lists' user.email %}">My lists</a></li>
    </ul>

22.5　下移一层到视图函数（控制器）

这样改还是会得到模板错误，所以要从表现层和 URL 层下移，进入控制器层，即 Django

中的视图函数。一如既往，先写测试：

lists/tests/test_views.py (ch19l003)

class MyListsTest(TestCase):
    def test_my_lists_url_renders_my_lists_template(self):
        response = self.client.get('listsusers/a@b.com/')
        self.assertTemplateUsed(response, 'my_lists.html')

得到的测试结果为：

AssertionError: No templates used to render the response

然后修正这个问题，不过还在表现层，更准确地说是 urls.py：

lists/urls.py

urlpatterns = [
    url(r'^new$', views.new_list, name='new_list'),
    url(r'^(\d+)/$', views.view_list, name='view_list'),
    url(r'^users/(.+)/$', views.my_lists, name='my_lists'),
]

修改之后会得到一个测试失败消息，告诉我们移到下一层之后要做什么：

AttributeError: module 'lists.views' has no attribute 'my_lists'

从表现层移到视图层，再定义一个最简单的占位视图：

lists/views.py (ch19l005)

def my_lists(request, email):
    return render(request, 'my_lists.html')

以及一个最简单的模板：

lists/templates/my_lists.html

{% extends 'base.html' %}
{% block header_text %}My Lists{% endblock %}

现在单元测试通过了，但功能测试毫无进展，报错说“My Lists”页面没有显示清单。功能测试希望这些清单可以点击，而且以第一个待办事项命名：

$ python3 manage.py test functional_tests.test_my_lists
[...]
selenium.common.exceptions.NoSuchElementException: Message: Unable to locate
element: Reticulate splines

22.6　使用由外而内技术，再让一个测试通过

仍然使用功能测试驱动每一步的开发工作。

再次从外层开始，编写模板代码，让“My Lists”页面实现设想的功能。现在，要指定希望从低层获取的 API。

22.6.1　快速重组模板的继承层级

基模板目前没有地方放置新内容了，而且“My Lists”页面不需要新建待办事项表单，所以把表单放到一个块中，需要时才显示：

lists/templates/base.html (ch19l007-1)

    <div class="row">
      <div class="col-md-6 col-md-offset-3 jumbotron">
        <div class="text-center">
          <h1>{% block header_text %}{% endblock %}</h1>
          {% block list_form %}
            <form method="POST" action="{% block form_action %}{% endblock %}">
              {{ form.text }}
              {% csrf_token %}
              {% if form.errors %}
                <div class="form-group has-error">
                  <div class="help-block">{{ form.text.errors }}</div>
                </div>
              {% endif %}
            </form>
          {% endblock %}
        </div>
      </div>
    </div>

lists/templates/base.html (ch19l007-2)

      <div class="row">
        <div class="col-md-6 col-md-offset-3">
          {% block table %}
          {% endblock %}
        </div>
      </div>
      <div class="row">
        <div class="col-md-6 col-md-offset-3">
          {% block extra_content %}
          {% endblock %}
        </div>
      </div>
    </div>
    <script src="staticjquery-3.1.1.min.js"></script>
    [...]

22.6.2　使用模板设计API

同时，在 my_lists.html 中覆盖 list_form 块，把块中的内容清空：

lists/templates/my_lists.html

{% extends 'base.html' %}
{% block header_text %}My Lists{% endblock %}
{% block list_form %}{% endblock %}

然后只在 extra_content 块中编写代码：

lists/templates/my_lists.html

[...]
{% block list_form %}{% endblock %}
{% block extra_content %}
    <h2>{{ owner.email }}'s lists</h2>  ➊
    <ul>
        {% for list in owner.list_set.all %}  ➋
            <li><a href="{{ list.get_absolute_url }}">{{ list.name }}</a></li>  ➌
        {% endfor %}
    </ul>
{% endblock %}

在这个模板中我们做了几个设计决策，这会对内层代码产生一定影响。

❶ 需要一个名为 owner 的变量，在模板中表示用户。

❷ 想使用 owner.list_set.all 遍历用户创建的清单（我碰巧知道 Django ORM 提供了这个属性）。

❸ 想使用 list.name 获取清单的名字，目前清单以其中的第一个待办事项命名。

　由外而内的 TDD 有时叫作“一厢情愿式编程”，我想你能看出为什么。我们先编写高层代码，这些代码建立在设想的低层基础之上，可是低层尚未实现。

再次运行功能测试，确认没有造成任何破坏，同时查看有无进展：

$ python manage.py test functional_tests
[...]
selenium.common.exceptions.NoSuchElementException: Message: Unable to locate
element: Reticulate splines
 
 ---------------------------------------------------------------------
Ran 8 tests in 77.613s
 
FAILED (errors=1)

虽然没进展，但至少没造成任何破坏。该提交了：

$ git add lists
$ git diff --staged
$ git commit -m "url, placeholder view, and first-cut templates for my_lists"

22.6.3　移到下一层：视图向模板中传入什么

现在，视图层要回应需求，为模板层提供所需的对象。这里要提供的是清单属主：

lists/tests/test_views.py (ch19l011)

from django.contrib.auth import get_user_model
User = get_user_model()
[...]
class MyListsTest(TestCase):
    def test_my_lists_url_renders_my_lists_template(self):
        [...]
    def test_passes_correct_owner_to_template(self):
        User.objects.create(email='wrong@owner.com')
        correct_user = User.objects.create(email='a@b.com')
        response = self.client.get('listsusers/a@b.com/')
        self.assertEqual(response.context['owner'], correct_user)

测试结果为：

KeyError: 'owner'

那就这么修改：

lists/views.py (ch19l012)

from django.contrib.auth import get_user_model
User = get_user_model()
[...]
def my_lists(request, email):
    owner = User.objects.get(email=email)
    return render(request, 'my_lists.html', {'owner': owner})

这样修改之后，新测试通过了，但还是能看到前一个测试导致的错误。只需在这个测试中添加一个用户即可：

lists/tests/test_views.py (ch19l013)

    def test_my_lists_url_renders_my_lists_template(self):
        User.objects.create(email='a@b.com')
        [...]

现在测试全部通过：

OK

22.7　视图层的下一个需求：新建清单时应该记录属主

下移到模型层之前，视图层还有一部分代码要用到模型：如果当前用户已经登录网站，需要一种方式把新建的清单指派给一个属主。

初期编写的测试如下所示：

lists/tests/test_views.py (ch19l014)

class NewListTest(TestCase):
    [...]
    def test_list_owner_is_saved_if_user_is_authenticated(self):
        user = User.objects.create(email='a@b.com')
        self.client.force_login(user)  ➊
        self.client.post('listsnew', data={'text': 'new item'})
        list_ = List.objects.first()
        self.assertEqual(list_.owner, user)

➊ 为了让测试客户端利用已登录用户的身份发送请求，必须先调用 force_login()。

这个测试得到的失败消息如下：

AttributeError: 'List' object has no attribute 'owner'

为了修正这个问题，可以尝试编写如下代码：

lists/views.py (ch19l015)

def new_list(request):
    form = ItemForm(data=request.POST)
    if form.is_valid():
        list_ = List()
        list_.owner = request.user
        list_.save()
        form.save(for_list=list_)
        return redirect(list_)
    else:
        return render(request, 'home.html', {"form": form})

但这个视图其实解决不了问题，因为还不知道怎么保存清单的属主：

    self.assertEqual(list_.owner, user)
AttributeError: 'List' object has no attribute 'owner'

抉择时刻：测试失败时是否要移入下一层

为了让这个测试通过，就目前的情况而言，要下移到模型层。但还有一个失败测试，要做的工作太多，现在下移可不明智。

可以采用另一种策略，使用驭件把测试和下层组件更明显地隔离开。

一方面，使用驭件要做的工作更多，而且驭件会让测试代码更难读懂。另一方面，如果应用更复杂，外部和内部之间的分层更多，测试就会涉及 3~5 层，在深入最底层实现关键功能之前，这些测试一直处于失败状态。测试无法通过，单就一层而言，我们就无法确定它是否能正常运行，只有等到最底层实现之后才有答案。

你在自己的项目中有可能也会遇到这样的抉择时刻。两种方式都要探讨。先走捷径，放任测试失败不管。下一章再回到这里，探讨如何使用增强隔离的方式。

下面做次提交，并且为这次提交打上标签，以便下一章能找到这个位置：

$ git commit -am "new_list view tries to assign owner but cant"
$ git tag revisit_this_point_with_isolated_tests

22.8　下移到模型层

使用由外而内技术得出了两个需求，需要在模型层实现：其一，想使用 .owner 属性为清单指派一个属主；其二，想使用 API owner.list_set.all 获取清单的属主。

针对这两个需求，先编写一个测试：

lists/tests/test_models.py (ch19l018)

from django.contrib.auth import get_user_model
User = get_user_model()
[...]
class ListModelTest(TestCase):
    def testgetabsolute_url(self):
        [...]
    def test_lists_can_have_owners(self):
        user = User.objects.create(email='a@b.com')
        list_ = List.objects.create(owner=user)
        self.assertIn(list_, user.list_set.all())

又得到了一个失败的单元测试：

    list_ = List.objects.create(owner=user)
    [...]
TypeError: 'owner' is an invalid keyword argument for this function

简单些，把模型写成下面这样：

from django.conf import settings
[...]
class List(models.Model):
    owner = models.ForeignKey(settings.AUTH_USER_MODEL)

可是我们希望属主可有可无。明确表明需求比含糊其辞强，而且测试还可以作为文档，所以再编写一个测试：

lists/tests/test_models.py (ch19l020)

    def test_list_owner_is_optional(self):
        List.objects.create()  # 不该抛出异常

正确的模型实现如下所示：

lists/models.py

from django.conf import settings
[...]
class List(models.Model):
    owner = models.ForeignKey(settings.AUTH_USER_MODEL, blank=True, null=True)
    def get_absolute_url(self):
        return reverse('view_list', args=[self.id])

现在运行测试，会看到以前见过的数据库错误：

    return Database.Cursor.execute(self, query, params)
django.db.utils.OperationalError: no such column: lists_list.owner_id

因为需要做一次迁移：

$ python manage.py makemigrations
Migrations for 'lists':
  lists/migrations/0006_list_owner.py
    - Add field owner to list

快成功了，不过还有几个错误：

ERROR: test_redirects_after_POST (lists.tests.test_views.NewListTest)
[...]
ValueError: Cannot assign "<SimpleLazyObject:
<django.contrib.auth.models.AnonymousUser object at 0x7f364795ef90>>":
"List.owner" must be a "User" instance.
ERROR: test_can_save_a_POST_request (lists.tests.test_views.NewListTest)
[...]
ValueError: Cannot assign "<SimpleLazyObject:
<django.contrib.auth.models.AnonymousUser object at 0x7f364795ef90>>":
"List.owner" must be a "User" instance.

现在回到视图层，做些清理工作。注意，这些错误发生在针对 new_list 视图的测试中，而且用户没有登录。仅当用户登录后才应该保存清单的属主。在第 19 章中定义的 .is_authenticated() 函数现在有用处了（用户未登录时，Django 使用 AnonymousUser 类表示用户，此时 .is_authenticated() 函数的返回值始终是 False）：

lists/views.py (ch19l023)

    if form.is_valid():
        list_ = List()
        if request.user.is_authenticated:
            list_.owner = request.user
        list_.save()
        form.save(for_list=list_)
        [...]

这样修改之后，测试通过了：

$ python manage.py test lists
[...]
.......................................
 ---------------------------------------------------------------------
Ran 39 tests in 0.237s
 
OK

现在是提交的好时机：

$ git add lists
$ git commit -m "lists can have owners, which are saved on creation."

最后一步：实现模板需要的.name属性

使用的由外而内设计方式还有最后一个需求，即清单根据其中第一个待办事项命名：

lists/tests/test_models.py (ch19l024)

    def test_list_name_is_first_item_text(self):
        list_ = List.objects.create()
        Item.objects.create(list=list_, text='first item')
        Item.objects.create(list=list_, text='second item')
        self.assertEqual(list_.name, 'first item')

lists/models.py (ch19l025)

    @property
        def name(self):
        return self.item_set.first().text

你可能无法相信，这样测试就能通过了，而且“My Lists”页面（如图 22-1）也能使用了。

$ python manage.py test functional_tests
[...]
Ran 8 tests in 93.819s
 
OK

图 22-1：光彩夺目的“My Lists”页面（也证明我在 Windows 中测试过）

Python 中的 @property 修饰器

如果你没见过 @property 修饰器，我告诉你，它的作用是把类中的方法转变成与属性一样，可以在外部访问。

这是 Python 语言一个强大的特性，因为很容易用它实现“鸭子类型”（duck typing），无须修改类的接口就能改变属性的实现方式。也就是说，如果想把 .name 改成模型真正的属性，在数据库中存储文本型数据，整个过程是完全透明的，只要兼顾其他代码，就能继续使用 .name 获取清单名，完全不用知道这个属性的具体实现方式。几年前，Raymond Hettinger 在Pycon 上针对这个话题做过一次出色的演讲。这个演讲对新手友好，我极力推荐你观看（除此之外，还涵盖众多符合 Python 风格的类设计实践方式）。

当然了，就算没使用 @property 修饰器，在 Django 的模板语言中还是会调用 .name 方法。不过这是 Django 专有的特性，不适用于一般的 Python 程序。

但这个过程中有作弊。测试山羊正满怀猜疑。实现下一层时前一层还有失败的测试。下一章要看一下增强测试隔离性如何编写测试。

由外而内的 TDD

• 由外而内的 TDD

  一种编写代码的方法，由测试驱动，从外层开始（表现层，GUI），然后逐步向内层移动，通过视图层或控制器层，最终达到模型层。这种方法的理念是由实际需要使用的功能驱动代码的编写，而不是在低层猜测需求。

• 一厢情愿式编程

  由外而内的过程有时也叫“一厢情愿式编程”。其实，任何 TDD 形式都涉及一厢情愿。我们总是为还未实现的功能编写测试。

• 由外而内技术的缺点

  由外而内技术也不是万灵药。这种技术鼓励我们关注用户立即就能看到的功能，但不会自动提醒我们为不是那么明显的功能编写关键测试，例如安全相关的功能。你自己要记得编写这些测试。

第 23 章　测试隔离和“倾听测试的心声”

前一章对视图层的失败单元测试放任不管，而是进入模型层编写更多的测试和更多的代码，以便让这个测试通过。

测试侥幸通过了，因为我们的应用很简单。我要强调一点，在复杂的应用中，选择这么做是很危险的。尚未确定高层是否真正完成之前就进入低层是一种冒险行为。

　感谢 Gary Bernhardt，他看了前一章的草稿，建议我深入介绍测试隔离。

确保各层之间相互隔离确实需要投入更多的精力（以及更多可怕的驭件），可是这么做能促使我们得到更好的设计。本章就以实例说明这一点。

23.1　重温抉择时刻：视图层依赖于尚未编写的模型代码

重温前一章的抉择时刻，那时 new_list 视图无法正常运行，因为清单还没有 .owner 属性。

我们要逆转时光，通过前面做的标签检出以前的代码，看一下使用隔离性更好的测试效果如何。

$ git checkout -b more-isolation # 为这次实验新建一个分支
$ git reset --hard revisit_this_point_with_isolated_tests

失败的测试是下面这个：

lists/tests/test_views.py

class NewListTest(TestCase):
    [...]
    def test_list_owner_is_saved_if_user_is_authenticated(self):
        user = User.objects.create(email='a@b.com')
        self.client.force_login(user)
        self.client.post('listsnew', data={'text': 'new item'})
        list_ = List.objects.first()
        self.assertEqual(list_.owner, user)

尝试使用的解决方法如下所示：

lists/views.py

def new_list(request):
    form = ItemForm(data=request.POST)
    if form.is_valid():
        list_ = List()
        list_.owner = request.user
        list_.save()
        form.save(for_list=list_)
        return redirect(list_)
    else:
        return render(request, 'home.html', {"form": form})

此时，这个视图测试是失败的，因为还未编写模型层：

    self.assertEqual(list_.owner, user)
AttributeError: 'List' object has no attribute 'owner'

　如果没有签出以前的代码并还原 lists/models.py，就不会看到这个错误。这一步一定要做。本章的目标之一是，看一下是否真能为还不存在的模型层编写测试。

23.2　首先尝试使用驭件实现隔离

清单还没有属主，但可以使用一些模拟技术让视图层测试认为有属主：

lists/tests/test_views.py (ch20l003)

from unittest.mock import patch
[...]
    @patch('lists.views.List')  ➊
    @patch('lists.views.ItemForm')  ➋
    def test_list_owner_is_saved_if_user_is_authenticated(
        self, mockItemFormClass, mockListClass  ➌
    ):
        user = User.objects.create(email='a@b.com')
        self.client.force_login(user)
        self.client.post('listsnew', data={'text': 'new item'})
        mock_list = mockListClass.return_value  ➍
        self.assertEqual(mock_list.owner, user)  ❺

❶ 模拟 List 模型的功能，获取视图创建的任何一个清单。

❷ 此外，还要模拟 ItemForm。如若不然，调用 form.save() 时，表单会抛出错误，因为无法在想创建的 Item 对象中使用驭件做外键。一旦开始使用驭件，就很难停手！

❸ 通过测试方法的参数注入驭件时，要按照声明驭件的相反顺序传入。有多个驭件时，方法的签名就是这么奇怪，习惯就好。

❹ 视图访问的清单实例是 List 驭件的返回值。

❺ 现在可以声明断言，判断清单对象是否设定了 .owner 属性。

现在运行测试应该可以通过：

$ python manage.py test lists
[...]
Ran 37 tests in 0.145s
OK

如果没通过，确保 views.py 中的视图代码和我前面给出的一模一样，使用的是 List()，而不是 List.objects.create。

　使用驭件有个局限，必须按照特定的方式使用 API。这是使用驭件对象要做出的妥协之一。

使用驭件的side_effect属性检查事件发生的顺序

这个测试的问题是，无意中把代码写错也可能侥幸通过测试。假设在指定属主之前不小心调用了 save 方法：

lists/views.py

    if form.is_valid():
        list_ = List()
        list_.save()
        list_.owner = request.user
        form.save(for_list=list_)
        return redirect(list_)

按照测试现在这种写法，它依旧可以通过：

OK

所以，严格来说，不仅要检查指定了属主，还要确保在清单对象上调用 save 方法之前就已经指定了。

使用驭件检查事件发生顺序的方法如下。可以模拟一个函数，作为侦件，检查调用这个侦件时周围的状态：

lists/tests/test_views.py (ch20l005)

    @patch('lists.views.List')
    @patch('lists.views.ItemForm')
    def test_list_owner_is_saved_if_user_is_authenticated(
        self, mockItemFormClass, mockListClass
    ):
        user = User.objects.create(email='a@b.com')
        self.client.force_login(user)
        mock_list = mockListClass.return_value
        def check_owner_assigned():  ➊
            self.assertEqual(mock_list.owner, user)
        mock_list.save.side_effect = check_owner_assigned  ➋
        self.client.post('listsnew', data={'text': 'new item'})
        mock_list.save.assert_called_once_with()  ➌

❶ 定义一个函数，在这个函数中就希望先发生的事件声明断言，即检查是否设定了清单的属主。

❷ 把这个检查函数赋值给后续事件的 side_effect 属性。当视图在驭件上调用 save 方法时，才会执行其中的断言。要保证在测试的目标函数调用前完成此次赋值。

❸ 最后，要确保设定了 side_effect 属性的函数一定会被调用，也就是要调用 .save() 方法。否则断言永远不会运行。

　使用驭件的副作用时有两个常见错误：第一，side_effect 属性赋值太晚，也就是在调用测试目标函数之后才赋值；第二，忘记检查是否调用了引起副作用的函数。说“常见”，是因为撰写本章时我多次同时犯了这两个错误。

现在，如果仍然使用前面有错误的代码，即指定属主和调用 save 方法的顺序不对，就会看到如下错误：

FAIL: test_list_owner_is_saved_if_user_is_authenticated
(lists.tests.test_views.NewListTest)
[...]
  File "...superlistslistsviews.py", line 17, in new_list
    list_.save()
[...]
  File "...superlistsliststests/test_views.py", line 74, in
check_owner_assigned
    self.assertEqual(mock_list.owner, user)
AssertionError: <MagicMock name='List().owner' id='140691452447208'> != <User:
User object>

注意看这个失败消息，它先尝试保存，然后才执行 side_effect 属性对应的函数。

可以按照下面的方式修改，让测试通过：

lists/views.py

    if form.is_valid():
        list_ = List()
        list_.owner = request.user
        list_.save()
        form.save(for_list=list_)
        return redirect(list_)

测试结果为：

OK

但是这个测试写得很丑！

23.3　倾听测试的心声：丑陋的测试表明需要重构

当你发现必须像这样编写测试，而且要做许多工作时，很有可能表明测试试图向你诉说什么。准备测试所需的数据用了 8 行代码（用户驭件用了 2 行，请求对象又用了 3 行，还有 3 行设定副作用函数），太多了。

这个测试试图告诉我们，视图做的工作太多了，既要创建表单，又要创建清单对象，还要决定是否保存清单的属主。

前面已经说过，可以把一部分工作交给表单类完成，把视图变得简单且易于理解一些。为什么要在视图中创建清单对象？或许 ItemForm.save 能代劳？为什么视图要决定是否保存 request.user ？这项任务也可以交给表单完成。

既然要把更多的任务交给表单，感觉应该为这个表单起个新名字。可以叫它 NewListForm，因为这个名字能更好地表明它的作用。最终，视图或许可以写成这样吧：

lists/views.py

# 先不输入这段代码，只是假设可以这么写
def new_list(request):
    form = NewListForm(data=request.POST)
    if form.is_valid():
        list_ = form.save(owner=request.user) # 创建List和Item对象
        return redirect(list_)
    else:
        return render(request, 'home.html', {"form": form})

这样多简洁！下面来看一下如何为这种写法编写完全隔离的测试。

23.4　以完全隔离的方式重写视图测试

首次尝试为这个视图编写的测试组件集成度太高，数据库层和表单层的功能完成之后才能通过。现在使用另一种方式，提高测试的隔离度。

23.4.1　为了新测试的健全性，保留之前的整合测试组件

把 NewListTest 类重名为 NewListViewIntegratedTest，再把尝试使用驭件保存属主的测试代码删掉，换成整合版本，而且暂时为这个测试方法加上 skip 修饰器：

lists/tests/test_views.py (ch20l008)

import unittest
[...]
class NewListViewIntegratedTest(TestCase):
    def test_can_save_a_POST_request(self):
        [...]
    @unittest.skip
    def test_list_owner_is_saved_if_user_is_authenticated(self):
        user = User.objects.create(email='a@b.com')
        self.client.force_login(user)
        self.client.post('listsnew', data={'text': 'new item'})
        list_ = List.objects.first()
        self.assertEqual(list_.owner, user)

　你听说过“集成测试”（integration test）这个术语吗？想知道它和“整合测试”（integrated test）的区别吗？请看第 26 章框注中的定义。

$ python manage.py test lists
[...]
Ran 37 tests in 0.139s
OK

23.4.2　完全隔离的新测试组件

从头开始编写测试，看看隔离测试能否驱动我们写出 new_list 视图的替代版本。把这个视图命名为 new_list2，放在旧版视图旁边。写好之后，再换用这个新视图，看看以前的整合测试是否仍然都能通过。

lists/views.py (ch20l009)

def new_list(request):
    [...]
def new_list2(request):
    pass

23.4.3　站在协作者的角度思考问题

重写测试时若想实现完全隔离，必须丢掉以前对测试的认识。以前我们认为视图的真正作用是操作数据库等，现在则要站在协作对象的角度，思考视图如何与之交互。

站在新的角度上，发现视图的主要协作者是表单对象。所以，为了完全掌控表单，以及按照我们一厢情愿想要的方式定义表单的功能，使用驭件模拟表单。

lists/tests/test_views.py (ch20l010)

from unittest.mock import patch
from django.http import HttpRequest
from lists.views import new_list2
[...]
@patch('lists.views.NewListForm')  ➋
class NewListViewUnitTest(unittest.TestCase):  ➊
    def setUp(self):
        self.request = HttpRequest()
        self.request.POST['text'] = 'new list item'  ➌
    def test_passes_POST_data_to_NewListForm(self, mockNewListForm):
        new_list2(self.request)
        mockNewListForm.assert_called_once_with(data=self.request.POST)  ➍

❶ 使用 Django 提供的 TestCase 类太容易写成整合测试。为了确保写出纯粹隔离的单元测试，只能使用 unittest.TestCase。

❷ 模拟 NewListForm 类（尚未定义）。类中的所有测试方法都会用到这个驭件，所以在类上模拟。

❸ 在 setUp 方法中手动创建了一个简单的 POST 请求，没有使用（太过整合的）Django 测试客户端。

❹ 然后检查视图要做的第一件事：在视图中使用正确的构造方法初始化它的协作者，即 NewListForm，传入的数据从请求中读取。

在这个测试的结果中首先会看到一个失败消息，报错视图中还没有 NewListForm。

AttributeError: <module 'lists.views' from '...superlistslistsviews.py'>
does not have the attribute 'NewListForm'

先编写一个占位表单类：

lists/views.py (ch20l011)

from lists.forms import ExistingListItemForm, ItemForm, NewListForm
[...]

以及：

lists/forms.py (ch20l012)

class ItemForm(forms.models.ModelForm):
    [...]
class NewListForm(object):
    pass
class ExistingListItemForm(ItemForm):
    [...]

看到了一个真正的失败消息：

AssertionError: Expected 'NewListForm' to be called once. Called 0 times.

按照如下的方式编写代码：

lists/views.py (ch20l012-2)

def new_list2(request):
    NewListForm(data=request.POST)

测试结果为：

$ python manage.py test lists
[...]
Ran 38 tests in 0.143s
OK

继续编写测试。如果表单中的数据有效，要在表单对象上调用 save 方法：

lists/tests/test_views.py (ch20l013)

from unittest.mock import patch, Mock
[...]
@patch('lists.views.NewListForm')
class NewListViewUnitTest(unittest.TestCase):
    def setUp(self):
        self.request = HttpRequest()
        self.request.POST['text'] = 'new list item'
        self.request.user = Mock()
    def test_passes_POST_data_to_NewListForm(self, mockNewListForm):
        new_list2(self.request)
        mockNewListForm.assert_called_once_with(data=self.request.POST)
    def test_saves_form_with_owner_if_form_valid(self, mockNewListForm):
        mock_form = mockNewListForm.return_value
        mock_form.is_valid.return_value = True
        new_list2(self.request)
        mock_form.save.assert_called_once_with(owner=self.request.user)

据此，可以写出如下视图：

lists/views.py (ch20l014)

def new_list2(request):
    form = NewListForm(data=request.POST)
    form.save(owner=request.user)

如果表单中的数据有效，让视图做一个重定向，把我们带到一个页面，查看表单刚刚创建的对象。所以要模拟视图的另一个协作者——redirect 函数：

lists/tests/test_views.py (ch20l015)

    @patch('lists.views.redirect')  ➊
    def test_redirects_to_form_returned_object_if_form_valid(
        self, mock_redirect, mockNewListForm  ➋
    ):
        mock_form = mockNewListForm.return_value
        mock_form.is_valid.return_value = True  ➌
        response = new_list2(self.request)
        self.assertEqual(response, mock_redirect.return_value)  ➍
        mock_redirect.assert_called_once_with(mock_form.save.return_value)  ❺

❶ 模拟 redirect 函数，不过这次直接在方法上模拟。

❷ patch 修饰器先应用最内层的那个，所以这个驭件在 mockNewListForm 之前传入方法。

❸ 指定测试的是表单中数据有效的情况。

❹ 检查视图的响应是否为 redirect 函数的结果。

❺ 然后检查调用 redirect 函数时传入的参数是否为在表单上调用 save 方法得到的对象。

据此，可以编写如下视图：

lists/views.py (ch20l016)

def new_list2(request):
    form = NewListForm(data=request.POST)
    list_ = form.save(owner=request.user)
    return redirect(list_)

测试结果为：

$ python manage.py test lists
[...]
Ran 40 tests in 0.163s
OK

然后测试表单提交失败的情况——如果表单中的数据无效，渲染首页的模板：

lists/tests/test_views.py (ch20l017)

    @patch('lists.views.render')
    def test_renders_home_template_with_form_if_form_invalid(
        self, mock_render, mockNewListForm
    ):
        mock_form = mockNewListForm.return_value
        mock_form.is_valid.return_value = False
        response = new_list2(self.request)
        self.assertEqual(response, mock_render.return_value)
        mock_render.assert_called_once_with(
            self.request, 'home.html', {'form': mock_form}
        )

测试的结果为：

AssertionError: <HttpResponseRedirect status_code=302, "te[114 chars]%3E"> !=
<MagicMock name='render()' id='140244627467408'>

　在驭件上调用断言方法时一定要运行测试，确认它会失败。因为输入断言函数时太容易出错，会导致调用的模拟方法没有任何作用。（我会写成 asssert_called_once_with，用了三个 s。你自己可以试一下！）

故意犯个错误，确保测试全面：

lists/views.py (ch20l018)

    def new_list2(request):
        form = NewListForm(data=request.POST)
        list_ = form.save(owner=request.user)
        if form.is_valid():
            return redirect(list_)
        return render(request, 'home.html', {'form': form})

测试本不应该通过却通过了！那就再写一个测试：

lists/tests/test_views.py (ch20l019)

    def test_does_not_save_if_form_invalid(self, mockNewListForm):
        mock_form = mockNewListForm.return_value
        mock_form.is_valid.return_value = False
        new_list2(self.request)
        self.assertFalse(mock_form.save.called)

这个测试会失败：

    self.assertFalse(mock_form.save.called)
AssertionError: True is not false

最终得到了一个精简的视图：

lists/views.py

def new_list2(request):
    form = NewListForm(data=request.POST)
    if form.is_valid():
        list_ = form.save(owner=request.user)
        return redirect(list_)
    return render(request, 'home.html', {'form': form})

测试结果为：

$ python manage.py test lists
[...]
Ran 42 tests in 0.163s
OK

23.5　下移到表单层

已经写好了视图函数，这个视图基于设想的表单 NewItemForm，而且这个表单现在还不存在。

需要在表单对象上调用 save 方法创建一个新清单，还要使用通过验证的 POST 数据创建一个新待办事项。如果直接使用 ORM，save 方法可以写成这样：

class NewListForm(models.Form):
    def save(self, owner):
        list_ = List()
        if owner:
            list_.owner = owner
        list_.save()
        item = Item()
        item.list = list_
        item.text = self.cleaned_data['text']
        item.save()

这种实现方式依赖于模型层的两个类，即 Item 和 List。那么隔离性好的测试应该怎么写呢？

class NewListFormTest(unittest.TestCase):
    @patch('lists.forms.List')  ➊
    @patch('lists.forms.Item')  ➊
    def test_save_creates_new_list_and_item_from_post_data(
        self, mockItem, mockList  ➊
    ):
        mock_item = mockItem.return_value
        mock_list = mockList.return_value
        user = Mock()
        form = NewListForm(data={'text': 'new item text'})
        form.is_valid()  ➋
        def check_item_text_and_list():
            self.assertEqual(mock_item.text, 'new item text')
            self.assertEqual(mock_item.list, mock_list)
            self.assertTrue(mock_list.save.called)
        mock_item.save.side_effect = check_item_text_and_list  ➌
        form.save(owner=user)
        self.assertTrue(mock_item.save.called)  ➍

❶ 为表单模拟两个来自下部模型层的协作者。

❷ 必须调用 is_valid() 方法，这样表单才会把通过验证的数据存储到 .cleaned_data 字典中。

❸ 使用 side_effect 方法确保保存新待办事项对象时，使用已经保存的清单，而且待办事项中的文本正确。

❹ 一如既往，再次确认调用了副作用函数。

唉，这个测试写得好丑！

始终倾听测试的心声：从应用中删除ORM代码

测试又在诉说什么：Django ORM 很难模拟，而且表单类需要较深入地了解 ORM 的工作方式。再次使用一厢情愿式编程，想想表单想用什么样的简单 API 呢？下面这种怎么样：

    def save(self):
        List.create_new(first_item_text=self.cleaned_data['text'])

又冒出个想法：要不在 List 类 1 中定义一个辅助函数，封装保存新清单对象及相关的第一个待办事项这部分逻辑。

1你很可能想定义一个单独的函数，但是放在类中有利于记住它在哪儿。更重要的是，还能表明这个函数的作用。嗯，我保证等我写完这本书之后会这么做的。尖锐的批评就此打住吧！

那就先为这个想法编写测试：

lists/tests/test_forms.py (ch20l021)

import unittest
from unittest.mock import patch, Mock
from django.test import TestCase
from lists.forms import (
    DUPLICATE_ITEM_ERROR, EMPTY_ITEM_ERROR,
    ExistingListItemForm, ItemForm, NewListForm
)
from lists.models import Item, List
[...]
class NewListFormTest(unittest.TestCase):
    @patch('lists.forms.List.create_new')
    def test_save_creates_new_list_from_post_data_if_user_not_authenticated(
        self, mock_Listcreatenew
    ):
        user = Mock(is_authenticated=False)
        form = NewListForm(data={'text': 'new item text'})
        form.is_valid()
        form.save(owner=user)
        mock_Listcreatenew.assert_called_once_with(
            first_item_text='new item text'
        )