第 18 章 完成My Lists页面:由外而内的TDD

第 18 章 完成 "My Lists" 页面:由外而内的 TDD

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

大多数人都凭直觉选择后者。提出一个设计想法之后，有时会自然而然地从最内部、最低层的组件开始实现。

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

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

由内而外的技术最明显的问题是它迫使我们抛开 TDD 流程。

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

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

由此相反，使用由外而内的工作方式，可以在外层组件的基础上构思想从内层组件获取的最佳 API。

18.3 "My Lists" 页面的功能测试

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

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

# functional_tests/test_my_lists.py
    def test_logged_in_users_lists_are_saved_as_my_lists(self):
        email = "[e-mail]"  # 这个邮箱成功了, 我自己的邮箱好像还要密码所以就失败了?

        self.browser.get(self.server_url)
        self.wait_to_be_logged_out(email)

        # Y 是已登录用户
        self.create_pre_authenticated_session(email)

        # self.browser.get(self.server_url)
        # self.wait_to_be_logged_in(email)

        # 她访问首页，新建一个清单
        self.browser.get(self.server_url)
        self.get_item_input_box().send_keys("Reticulate splines\n")
        self.get_item_input_box().send_keys("Immanentize eschaton\n")
        first_list_url = self.browser.current_url

        # 她第一次看到 My Lists 链接
        self.browser.find_element_by_link_text("My Lists").click()

        # 她看到这个页面中有她创建的清单
        # 而且清单根据第一个待办事项命名
        self.browser.find_element_by_link_text("Reticulate splines").click()
        self.assertEqual(self.browser.current_url, first_list_url)

        # 她决定再建一个清单试试
        self.browser.get(self.server_url)
        self.get_item_input_box().send_keys("Click cows\n")
        second_list_url = self.browser.current_url

        # 在 My Lists 页面，这个新建的清单也显示出来了
        self.browser.find_element_by_link_text("My Lists").click()
        self.browser.find_element_by_link_text("Click cows").click()
        self.assertEqual(self.browser.current_url, second_list_url)

        # 她退出后, My Lists 链接不见了
        self.browser.find_element_by_id("id_logout").click()
        self.assertEqual(self.browser.find_elements_by_link_text("My Lists"), [])

运行这个测试，可以看到预期的错误。

python3.4 manage.py test functional_tests.test_my_lists.MyListsTest.test_logged_in_users_lists_are_saved_as_my_lists

18.4 外层：表现层和模板

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

<!-- lists/templates/base.html -->
{% if user.email %}
    <ul class="nav navbar-nav">
      <li><a href="#">My Lists</a></li>
    </ul>
    <a class="btn navbar-btn navbar-right" id="id_logout" [...]

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

失败消息指出要构建一个页面，用标题列出一个用户的所有清单。

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

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

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

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

先写测试：

# lists/tests/test_views.py
class MyListsTest(TestCase):
    def test_my_lists_url_renders_my_lists_template(self):
        response = self.client.get("/lists/users/[e-mail]")
        self.assertTemplateUsed(response, "my_lists.html")

得到预期的失败测试结果。

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

# lists/urls.py
urlpatterns = [
    url(r"^(\d+)/$", lists.views.view_list, name="view_list"),
    url(r"^new$", lists.views.new_list, name="new_list"),
    url(r"^users/(.+)/$", "lists.views.my_lists", name="my_lists")
]

修改之后会得到另一个测试失败消息。

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

# lists/views.py
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 %}

现在单元测试通过了，但功能测试毫无进展。

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

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

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

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

<!-- lists/templates/base.html -->
<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.erros %}
    <div class="form-group has-error">
      <div class="help-block">
        {{ form.text.errors }}
      </div>
    </div>
    {% endif %}
  </form>
  {% endblock %}
</div>
[...]
    <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>

18.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 的变量，在模板中表示用户 -->
        {{ owner.email }}'s lists
    </h2>
    <ul>
        <!-- 想使用 owner.list_set.all 遍历用户创建的清单(ORM 提供了这个属性) -->
        {% for list in owner.list_set.all %}
            <!-- 想使用 list.name 获取清单的名字，目前清单以其中的第一个待办事项命名 -->
            <li><a href="{{ list.get_absolute_url }}">{{ list.name }}</a></li>
        {% endfor %}
    </ul>
{% endblock %}

再次运行功能测试，确认没有造成任何破坏，或者是有所进展：

python3 manage.py test functional_tests

该提交了：

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

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

# lists/tests/test_views.py
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="[e-mail]")
        correct_user = User.objects.create(email="[e-mail]")
        response = self.client.get("/lists/users/[e-mail]/")
        self.assertEqual(response.context["owner"], correct_user)

视图没有传入 owner，于是：

# lists/views.py
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
def test_my_lists_url_renders_my_lists_template(self):
    User.objects.create(email="[e-mail]")
    [...]

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

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

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

# lists/tests/test_views.py
from django.http import HttpRequest
[...]
from lists.views import new_list
[...]

class NewListTest(TestCase):
    [...]

    def test_list_owner_is_saved_if_user_is_authenticated(self):
        request = HttpRequest()
        request.user = User.objects.create(email="[e-mail]")
        request.POST["text"] = "new list item"
        new_list(request)
        list_ = List.objects.first()
        self.assertEqual(list_.owner, request.user)

这个测试直接调用视图函数，而且手动构造了一个 HttpRequest 对象，因为这么写测试稍微简单些。虽然 Django 测试客户端提供了辅助函数 login，但在外部认证系统中用起来并不顺手。此外，还可以手动创建会话对象，或者使用驭件。不过这两种方式写出来的代码并不好看。

按照测试失败的消息来改进代码，首先尝试如下编写：

# 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})

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

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

为了让这个测试通过，要下移到模型层。

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

一方面，使用驭件要做的工作更多，而且驭件会让测试代码更难读懂。另一方面，如果应用更复杂，外部和内部之间的分层更多，测试就会涉及多层。

这里先走捷径，放任测试失败不管。

下面做次提交，并且为这次提交打上标签。

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

18.8 下移到模型层

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

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

# lists/tests/test_models.py
from django.contrib.auth import get_user_model
User = get_user_model()
[...]

class ListModelTest(TestCase):
    def test_get_absolute_url(self):
        [...]

    def test_lists_can_have_owners(self):
        user = User.objects.create(email="[e-mail]")
        list_ = List.objects.create(owner=user)
        self.assertIn(list_, user.list_set.all())

得到了一个失败的单元测试，接着把模型写成下面这样：

from django.conf import settings
[...]

class List(models.Model):
    owner = models.ForeignKey(settings.AUTH_USER_MODEL)

可是我们希望属主可有可无，所以再编写一个测试来明确表示需求：

# lists/tests/test_models.py
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])

现在运行测试，会看到数据库错误，因此需要做一次迁移。

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

# lists/views.py
if form.is_valid():
    list_ = List()
    if request.user.is_authenticated():
        list_.owner = request.user
    list_.save()
    form.save(for_list=list_)
    [...]

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

现在是提交的好时机了：

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

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

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

# lists/tests/test_models.py
def test_list_name_is_first_item_text(self):
    list_ = List.objects.create()
    Item.objects.create(list_attr=list_, text="first item")
    Item.objects.create(list_attr=list_, text="second item")
    self.assertEqual(list_.name, "first item")

# lists/models.py
@property
def name(self):
    return self.item_set.first().text

这样测试就能通过了，而且 "My Lists" 页面也能使用了。

Python 中的 @property 修饰器

该修饰器的作用是把类中的方法转变成与属性一样，可以在外部访问。

这是 Python 语言一个强大的特性，因为很容易用它实现“鸭子类型”（duck typing），无需修改类的接口就能改变属性的实现方式。也就是说，如果想把 .name 改成模型真正的属性，在数据库中存储文本型数据，整个过程是完全透明的，只要兼顾其他代码，就能继续使用 .name 获取清单名，完全不用知道这个属性的具体实现方式。

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

由外而内的 TDD

• 由外而内的 TDD

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

• 一厢情愿式编程

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

• 由外而内技术的缺点

  • 由外而内技术鼓励我们关注用户立即就能看到的功能，但不会自动提醒我们为不是那么明显的功能编写关键测试，例如安全相关的功能。