7.8.2　用于新建清单的URL和视图

下面添加新的 URL 映射：

superlists/urls.py

urlpatterns = [
    url(r'^$', views.home_page, name='home'),
    url(r'^lists/new$', views.new_list, name='new_list'),
    url(r'^lists/the-only-list-in-the-world/$', views.view_list, name='view_list'),
]

再运行测试，会得到 no attribute'new_list' 错误。修正这个问题，在文件 lists/views.py 中写入：

lists/views.py (ch07l023-1)

def new_list(request):
    pass

再运行测试，得到的失败消息是：“The view lists.views.new_list didn't return an HttpResponse object”（lists.views.new_list 视图没返回 HttpResponse 对象）。这个消息很眼熟。虽然可以返回一个原始的 HttpResponse 对象，但既然知道需要的是重定向，那就从 home_page 视图中借用一行代码吧：

lists/views.py (ch07l023-2)

def new_list(request):
    return redirect('liststhe-only-list-in-the-world/')

现在测试的结果是：

    self.assertEqual(Item.objects.count(), 1)
AssertionError: 0 != 1

失败消息简洁易懂。再从 home_page 视图中借用一行代码：

lists/views.py (ch07l023-3)

def new_list(request):
    Item.objects.create(text=request.POST['item_text'])
    return redirect('liststhe-only-list-in-the-world/')

加入这行代码后，测试便能通过了：

Ran 7 tests in 0.030s
OK

而且功能测试表明，我们又回到了正常状态：

[...]
AssertionError: '1: Buy milk' not found in ['1: Buy peacock feathers', '2: Buy
milk']
Ran 2 tests in 8.972s
FAILED (failures=1)

7.8.3　删除当前多余的代码和测试

看起来不错。既然新视图完成了以前 home_page 视图的大部分工作，应该就可以大幅度精简 home_page 了。比如说，可以删除整个 if request.method == 'POST' 部分吗？

lists/views.py

def home_page(request):
    return render(request, 'home.html')

当然可以！

OK

既然已经动手简化了，还可以把当前多余的测试方法 test_only_saves_items_when_necessary 也删掉。

删掉之后是不是感觉挺好的？视图函数变得更简洁了。再次运行测试，确认一切正常：

Ran 6 tests in 0.016s
OK

那功能测试呢？

7.8.4　出现回归！让表单指向刚添加的新URL

糟糕：

ERROR: test_can_start_a_list_for_one_user
[...]
  File "...superlists/functional_tests/tests.py", line 57, in
test_can_start_a_list_for_one_user
    self.wait_for_row_in_list_table('1: Buy peacock feathers')
  File "...superlists/functional_tests/tests.py", line 23, in
wait_for_row_in_list_table
    table = self.browser.find_element_by_id('id_list_table')
selenium.common.exceptions.NoSuchElementException: Message: Unable to locate
element: [id="id_list_table"]
ERROR: test_multiple_users_can_start_lists_at_different_urls
[...]
  File "...superlists/functional_tests/tests.py", line 79, in
test_multiple_users_can_start_lists_at_different_urls
    self.wait_for_row_in_list_table('1: Buy peacock feathers')
selenium.common.exceptions.NoSuchElementException: Message: Unable to locate
element: [id="id_list_table"]
[...]
Ran 2 tests in 11.592s
FAILED (errors=2)

这是因为表单依然指向旧的 URL。在 home.html 和 lists.html 中，把表单改成：

lists/templates/home.html, lists/templates/list.html

    <form method="POST" action="listsnew">

这样就能回到之前的状态了：

AssertionError: '1: Buy milk' not found in ['1: Buy peacock feathers', '2: Buy
milk']
[...]
FAILED (failures=1)

以上操作可以作为一次完整的提交：对 URL 映射做了些改动，views.py 看起来也精简多了，而且能保证应用还能像以前那样正常运行。我们的重构技术变得越来越好了！

$ git status # 5个改动的文件
$ git diff # 在两个表单中添加了URL，视图和测试都有代码移动，还添加了一个新URL
$ git commit -a

可以在待办事项清单中划掉一个问题了：

7.9　下定决心，调整模型

关于 URL 的清理工作做得够多了，现在下定决心修改模型。先调整模型的单元测试。这次换种方式，以差异的形式表示改动的地方：

lists/tests.py

@@ -1,5 +1,5 @@
  from django.test import TestCase
-from lists.models import Item
+from lists.models import Item, List
  class HomePageTest(TestCase):
@@ -44,22 +44,32 @@ class ListViewTest(TestCase):
-class ItemModelTest(TestCase):
+class ListAndItemModelsTest(TestCase):
    def test_saving_and_retrieving_items(self):
+       list_ = List()
+       list_.save()
+
        first_item = Item()
        first_item.text = 'The first (ever) list item'
+       first_item.list = list_
        first_item.save()
        second_item = Item()
        second_item.text = 'Item the second'
+       second_item.list = list_
        second_item.save()
+       saved_list = List.objects.first()
+       self.assertEqual(saved_list, list_)
+
        saved_items = Item.objects.all()
        self.assertEqual(saved_items.count(), 2)
        first_saved_item = saved_items[0]
        second_saved_item = saved_items[1]
        self.assertEqual(first_saved_item.text, 'The first (ever) list item')
+       self.assertEqual(first_saved_item.list, list_)
        self.assertEqual(second_saved_item.text, 'Item the second')
+       self.assertEqual(second_saved_item.list, list_)

新建了一个 List 对象，然后通过给 .list 属性赋值把两个待办事项归在这个对象名下。要检查这个清单是否正确保存，也要检查是否保存了那两个待办事项与清单之间的关系。你还会注意到可以直接比较两个清单（saved_list 和 list_）——其实比较的是两个清单的主键（.id 属性）是否相同。

　我使用变量名 list_ 的目的是防止遮盖 Python 原生的 list 函数。这么写可能不美观，但我能想到的其他写法也同样不美观，或者更糟，比如 my_list、the_list、list1 和 listey 等。

现在要开始另一个“单元测试 / 编写代码”循环了。

在前几次迭代中，我只给出每次运行测试时期望看到的错误消息，不会告诉你运行测试前要输入哪些代码，你要自己编写每次所需的最少代码改动。

　需要提示？翻回第 5 章，参照引入 Item 模型的步骤。

你首先看到的错误消息是：

ImportError: cannot import name 'List'

解决这个错误后，再次运行测试会看到：

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

然后会看到：

django.db.utils.OperationalError: no such table: lists_list

因此需要执行一次 makemigrations 命令：

$ python manage.py makemigrations
Migrations for 'lists':
  lists/migrations/0003_list.py
    - Create model List

然后会看到：

    self.assertEqual(first_saved_item.list, list_)
AttributeError: 'Item' object has no attribute 'list'

7.9.1　外键关系

Item 的 list 属性应该怎么实现呢？先天真一点，把它当成 text 属性试试（你可以借机看一下你的实现方式与我的有什么区别）：

lists/models.py

from django.db import models
class List(models.Model):
    pass
class Item(models.Model):
    text = models.TextField(default='')
    list = models.TextField(default='')

照例，测试会告诉我们需要做一次迁移：

$ python manage.py test lists
[...]
django.db.utils.OperationalError: no such column: lists_item.list
 
$ python manage.py makemigrations
Migrations for 'lists':
  lists/migrations/0004_item_list.py
    - Add field list to item

看一下测试结果如何：

AssertionError: 'List object' != <List: List object>

离成功还有一段距离。请仔细看 != 两边的内容。Django 只保存了 List 对象的字符串形式。若想保存对象之间的关系，要告诉 Django 两个类之间的关系，这种关系使用 ForeignKey 字段表示：

lists/models.py

from django.db import models
class List(models.Model):
    pass
class Item(models.Model):
    text = models.TextField(default='')
    list = models.ForeignKey(List, default=None)

修改之后也要做一次迁移。既然前一个迁移没用了，就把它删掉吧，换一个新的：

$ rm lists/migrations/0004_item_list.py
$ python manage.py makemigrations
Migrations for 'lists':
  lists/migrations/0004_item_list.py
    - Add field list to item

　删除迁移是种危险操作，但偶尔需要这么做，因为不可能从一开始就正确定义模型。如果删除已经用于某个数据库的迁移，Django 就不知道当前状态，因此也就不知道如何运行以后的迁移。只有当你确定某个迁移没被使用时才能将其删除。根据经验，已经提交到 VCS 的迁移决不能删除。

7.9.2　根据新模型定义调整其他代码

再看测试的结果如何：

$ python manage.py test lists
[...]
ERROR: test_displays_all_items (lists.tests.ListViewTest)
django.db.utils.IntegrityError: NOT NULL constraint failed: lists_item.list_id
[...]
ERROR: test_redirects_after_POST (lists.tests.NewListTest)
django.db.utils.IntegrityError: NOT NULL constraint failed: lists_item.list_id
[...]
ERROR: test_can_save_a_POST_request (lists.tests.NewListTest)
django.db.utils.IntegrityError: NOT NULL constraint failed: lists_item.list_id
 
Ran 6 tests in 0.021s
 
FAILED (errors=3)

天啊，这么多错误。

可是也有一些好消息。虽然很难看出，不过模型测试通过了。但是三个视图测试出现了重大错误。

出现这些错误是因为我们在待办事项和清单之间建立了关联，在这种关联中，每个待办事项都需要一个父级清单，但是原来的测试和代码并没有考虑到这一点。

不过，这正是测试的目的所在。下面要让测试再次通过。最简单的方法是修改 ListViewTest，为测试中的两个待办事项创建父清单：

lists/tests.py (ch07l031)

class ListViewTest(TestCase):
    def test_displays_all_items(self):
        list_ = List.objects.create()
        Item.objects.create(text='itemey 1', list=list_)
        Item.objects.create(text='itemey 2', list=list_)

修改之后，失败测试减少到两个，而且都是向 new_list 视图发送 POST 请求引起的。使用惯用的技术分析调用跟踪，由错误消息找到导致错误的测试代码，然后再找出相应的应用代码，最终定位到下面这行：

File "...superlistslistsviews.py", line 9, in new_list
Item.objects.create(text=request.POST['item_text'])

这行调用跟踪表明创建待办事项时没有指定父清单。因此，要对视图做类似修改：

lists/views.py

from lists.models import Item, List
[...]
def new_list(request):
    list_ = List.objects.create()
    Item.objects.create(text=request.POST['item_text'], list=list_)
    return redirect('liststhe-only-list-in-the-world/')

修改之后，测试又能通过了：

Ran 6 tests in 0.030s
OK

此时你是不是感觉不舒畅？我们为每个新建的待办事项都指定了所属的清单，但还是集中显示所有待办事项，好像它们都属于同一个清单似的——感觉这么做完全不对。我知道不对，我也有同样的感觉。我们采用的步进方式与直觉不一致，要求代码从一个可用状态变成另一个可用状态。我总想直接动手一次修正所有问题，而不想把一个奇怪的半成品变成另一个半成品。可是你还记得测试山羊吗？爬山时，你要审慎抉择每一步踏在何处，而且一次只能迈一步，确认脚踩的每一个位置都不会让你跌落悬崖。

因此，为了确信一切都能正常运行，要再次运行功能测试：

AssertionError: '1: Buy milk' not found in ['1: Buy peacock feathers', '2: Buy
milk']
[...]

毫无疑问，测试的结果和修改前一样。现有功能没有破坏，在此基础上还修改了数据库。这一点令人欣喜！下面提交：

$ git status # 改动了3个文件，还新建了2个迁移
$ git add lists
$ git diff --staged
$ git commit

又可以从待办事项清单上划掉一个问题了：

7.10　每个列表都应该有自己的URL

应该使用什么作为清单的唯一标识符呢？就目前而言，或许最简单的处理方式是使用数据库自动生成的 id 字段。下面修改 ListViewTest，让其中的两个测试指向新 URL。

还要把 test_displays_all_items 测试重命名为 test_displays_only_items_for_that_list，然后在这个测试中确认只显示属于这个清单的待办事项：

lists/tests.py (ch07l033)

class ListViewTest(TestCase):
    def test_uses_list_template(self):
        list_ = List.objects.create()
        response = self.client.get(f'lists{list_.id}/')
        self.assertTemplateUsed(response, 'list.html')
    def test_displays_only_items_for_that_list(self):
        correct_list = List.objects.create()
        Item.objects.create(text='itemey 1', list=correct_list)
        Item.objects.create(text='itemey 2', list=correct_list)
        other_list = List.objects.create()
        Item.objects.create(text='other list item 1', list=other_list)
        Item.objects.create(text='other list item 2', list=other_list)
        response = self.client.get(f'lists{correct_list.id}/')
        self.assertContains(response, 'itemey 1')
        self.assertContains(response, 'itemey 2')
        self.assertNotContains(response, 'other list item 1')
        self.assertNotContains(response, 'other list item 2')

　这个代码清单又用到了几个 f 字符串。如果你还是不太了解，看一下文档（https://docs.python.org/3/reference/lexical_analysis.html#f-strings）。（如果你跟我一样没正式学习过 CS，或许应该跳过正式的语法。）

运行这个单元测试，会看到预期的 404，以及另一个相关的错误：

FAIL: test_displays_only_items_for_that_list (lists.tests.ListViewTest)
AssertionError: 404 != 200 : Couldn't retrieve content: Response code was 404
(expected 200)
[...]
FAIL: test_uses_list_template (lists.tests.ListViewTest)
AssertionError: No templates used to render the response

7.10.1　捕获URL中的参数

现在要学习如何把 URL 中的参数传入视图：

superlists/urls.py

urlpatterns = [
    url(r'^$', views.home_page, name='home'),
    url(r'^lists/new$', views.new_list, name='new_list'),
    url(r'^lists/(.+)/$', views.view_list, name='view_list'),
]

调整 URL 映射中使用的正则表达式，加入一个捕获组（capture group，.+），它能匹配随后 / 之前的任意个字符。捕获得到的文本会作为参数传入视图。

也就是说，如果访问 lists1/，view_list 视图除了常规的 request 参数之外，还会获得第二个参数，即字符串 "1"。如果访问 listsfoo/，视图就是 view_list(request, "foo")。

但是视图并未期待有参数传入，毫无疑问，这么做会导致问题：

ERROR: test_displays_only_items_for_that_list (lists.tests.ListViewTest)
[...]
TypeError: view_list() takes 1 positional argument but 2 were given
[...]
ERROR: test_uses_list_template (lists.tests.ListViewTest)
[...]
TypeError: view_list() takes 1 positional argument but 2 were given
[...]
ERROR: test_redirects_after_POST (lists.tests.NewListTest)
[...]
TypeError: view_list() takes 1 positional argument but 2 were given
FAILED (errors=3)

这个问题容易修正，在 views.py 中加入一个参数即可：

lists/views.py

def view_list(request, list_id):
    [...]

现在，前面那个预期失败解决了：

FAIL: test_displays_only_items_for_that_list (lists.tests.ListViewTest)
[...]
AssertionError: 1 != 0 : Response should not contain 'other list item 1'

接下来要让视图决定把哪些待办事项传入模板：

lists/views.py

def view_list(request, list_id):
    list_ = List.objects.get(id=list_id)
    items = Item.objects.filter(list=list_)
    return render(request, 'list.html', {'items': items})

7.10.2　按照新设计调整new_list视图

现在得到发生在另一个测试中的错误：

ERROR: test_redirects_after_POST (lists.tests.NewListTest)
ValueError: invalid literal for int() with base 10:
'the-only-list-in-the-world'

既然这个测试报错了，就来看看它的代码吧：

lists/tests.py

class NewListTest(TestCase):
    [...]
    def test_redirects_after_POST(self):
        response = self.client.post('listsnew', data={'item_text': 'A new list item'})
        self.assertRedirects(response, 'liststhe-only-list-in-the-world/')

看样子这个测试还没按照清单和待办事项的新设计调整，它应该检查视图是否重定向到指定新建清单的 URL：

lists/tests.py (ch07l036-1)

    def test_redirects_after_POST(self):
        response = self.client.post('listsnew', data={'item_text': 'A new list item'})
        new_list = List.objects.first()
        self.assertRedirects(response, f'lists{new_list.id}/')

修改后测试还是得到无效字面量错误。检查一下视图本身，把它改为重定向到有效的地址：

lists/views.py (ch07l036-2)

def new_list(request):
    list_ = List.objects.create()
    Item.objects.create(text=request.POST['item_text'], list=list_)
    return redirect(f'lists{list_.id}/')

这样修改之后单元测试就可以通过了：

$ python3 manage.py test lists
[...]
......
 ---------------------------------------------------------------------
Ran 6 tests in 0.033s
 
OK

那么功能测试结果如何？差不多也能通过吧？

7.11　功能测试又检测到回归

嗯，快了：

F.

FAIL: test_can_start_a_list_for_one_user

新测试其实通过了，不同的用户有不同的清单，但是旧测试提醒我们出现了回归。看起来无法在清单中添加第二个待办事项。这是因为我们投机取巧了，每次 POST 提交都新建一个清单。这正是编写功能测试的目的！

而这正好和待办事项清单中最后一个问题高度吻合：

7.12　还需要一个视图，把待办事项加入现有清单

还需要一个 URL 和视图（lists/add_item），把新待办事项添加到现有的清单中。我们已经熟知这种操作了，因此可以一次写好两个测试：

lists/tests.py

class NewItemTest(TestCase):
    def test_can_save_a_POST_request_to_an_existing_list(self):
        other_list = List.objects.create()
        correct_list = List.objects.create()
        self.client.post(
            f'lists{correct_list.id}/add_item',
            data={'item_text': 'A new item for an existing list'}
        )
        self.assertEqual(Item.objects.count(), 1)
        new_item = Item.objects.first()
        self.assertEqual(new_item.text, 'A new item for an existing list')
        self.assertEqual(new_item.list, correct_list)
    def test_redirects_to_list_view(self):
        other_list = List.objects.create()
        correct_list = List.objects.create()
        response = self.client.post(
            f'lists{correct_list.id}/add_item',
            data={'item_text': 'A new item for an existing list'}
        )
        self.assertRedirects(response, f'lists{correct_list.id}/')

　你是不是觉得奇怪，想知道为什么要用 other_list ？这与查看某个清单的测试类似，要确保把待办事项添加到特定的清单中。在数据库中再存储一个对象便无须使用 List.objects.first() 这样可能出错的代码。那样做是不对的，如果真做了，你可能会为之付出惨痛代价（毕竟数字有无穷多个）。这只是主观选择，不过我觉得值得这么做。详情请参见 15.1.1 节。

测试的结果为：

AssertionError: 0 != 1
[...]
AssertionError: 301 != 302 : Response didn't redirect as expected: Response
code was 301 (expected 302)

7.12.1　小心霸道的正则表达式

有点奇怪，还没在 URL 映射中加入 lists1/add_item，应该得到 404 != 302 错误，怎么会是 301 呢？

确实令人费解。其实得到这个错误是因为在 URL 映射中使用了一个非常霸道的正则表达式：

superlists/urls.py

    url(r'^lists/(.+)/$', views.view_list, name='view_list'),

根据 Django 的内部处理机制，如果访问的 URL 几乎正确，但却少了末尾的斜线，就会得到一个永久重定向响应（301）。在这里，lists1/add_item/ 符合 lists/(.+)/ 的匹配模式，其中 (.+) 捕获 1/add_item，所以 Django 伸出“援手”，猜测你其实是想访问末尾带斜线的 URL。

这个问题的修正方法是，显式指定 URL 模式只捕获数字，即在正则表达式中使用 \d：

superlists/urls.py

    url(r'^lists/(\d+)/$', views.view_list, name='view_list'),

修改后测试的结果是：

AssertionError: 0 != 1
[...]
AssertionError: 404 != 302 : Response didn't redirect as expected: Response
code was 404 (expected 302)

7.12.2　最后一个新URL

现在得到了预期的 404。下面定义一个新 URL，用于把新待办事项添加到现有清单中：

superlists/urls.py

urlpatterns = [
    url(r'^$', views.home_page, name='home'),
    url(r'^lists/new$', views.new_list, name='new_list'),
    url(r'^lists/(\d+)/$', views.view_list, name='view_list'),
    url(r'^lists/(\d+)/add_item$', views.add_item, name='add_item'),
]

现在 URL 映射中定义了三个类似的 URL。在待办事项清单中做个记录，因为这三个 URL 看起来需要重构。

再看测试，现在又提示视图模块缺少属性：

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

7.12.3　最后一个新视图

定义下面这个视图试试：

lists/views.py

def add_item(request):
    pass

效果不错：

TypeError: add_item() takes 1 positional argument but 2 were given

继续修改视图：

lists/views.py

def add_item(request, list_id):
    pass

测试的结果是：

ValueError: The view lists.views.add_item didn't return an HttpResponse object.
It returned None instead.

可以从 new_list 视图中复制 redirect，从 view_list 视图中复制 List.objects.get：

lists/views.py

def add_item(request, list_id):
    list_ = List.objects.get(id=list_id)
    return redirect(f'lists{list_.id}/')

现在测试的结果为：

    self.assertEqual(Item.objects.count(), 1)
AssertionError: 0 != 1

最后，让视图保存新建的待办事项：

lists/views.py

def add_item(request, list_id):
    list_ = List.objects.get(id=list_id)
    Item.objects.create(text=request.POST['item_text'], list=list_)
    return redirect(f'lists{list_.id}/')

这样，测试又能通过了：

Ran 8 tests in 0.050s
OK

7.12.4　直接测试响应上下文对象

把待办事项添加到现有清单所需的视图和 URL 都有了，现在只剩在 list.html 模板中使用它们了。打开这个模板，修改表单标签：

lists/templates/list.html

    <form method="POST" action="but what should we put here?">

可是，若想获取添加到当前清单的 URL，模板要知道它渲染的是哪个清单，以及要添加哪些待办事项。希望表单能写成下面这样：

lists/templates/list.html

    <form method="POST" action="lists{{ list.id }}/add_item">

为了能这样写，视图要把清单传入模板。下面在 ListViewTest 中新建一个单元测试方法：

lists/tests.py (ch07l041)

    def test_passes_correct_list_to_template(self):
        ther_list = List.objects.create()
        orrect_list = List.objects.create()
        esponse = self.client.get(f'lists{correct_list.id}/')
        elf.assertEqual(response.context['list'], correct_list)  ➊

➊ response.context 表示要传入 render 函数的上下文——Django 测试客户端把上下文附在 response 对象上，方便测试。

增加这个测试后得到的结果如下：

KeyError: 'list'

这是因为没把 list 传入模板，其实也给了我们一个简化视图的机会：

lists/views.py

def view_list(request, list_id):
    list_ = List.objects.get(id=list_id)
    return render(request, 'list.html', {'list': list_})

这么做显然会破坏一个旧测试，因为模板需要 items：

FAIL: test_displays_only_items_for_that_list (lists.tests.ListViewTest)
[...]
AssertionError: False is not true : Couldn't find 'itemey 1' in response

可以在 list.html 中修正这个问题，同时还要修改表单 POST 请求的目标地址，即 action 属性：

lists/templates/list.html (ch07l043)

    <form method="POST" action="lists{{ list.id }}/add_item">  ➊
      [...]
      {% for item in list.item_set.all %}  ➋
        <tr><td>{{ forloop.counter }}: {{ item.text }}</td></tr>
      {% endfor %}

➊ 这是新的目标地址。

➋ .item_set 叫作反向查询（reverse lookup），是 Django 提供的非常有用的 ORM 功能，作用是在其他表中查询某个对象的相关记录。

修改模板之后，单元测试能通过了：

Ran 9 tests in 0.040s
OK

功能测试的结果如何呢？

$ python manage.py test functional_tests
[...]
..
 ---------------------------------------------------------------------
Ran 2 tests in 9.771s
 
OK

太好了！再看一下待办事项清单：

可惜，测试山羊也是善始不善终的，还有最后一个问题没解决。

在解决这个问题之前，先做提交——着手重构之前一定要提交可正常运行的代码：

$ git diff
$ git commit -am "new URL + view for adding to existing lists. FT passes :-)"

7.13　使用URL引入做最后一次重构

superlists/urls.py 的真正作用是定义整个网站使用的 URL。如果某些 URL 只在 lists 应用中使用，Django 建议使用单独的文件 lists/urls.py，让应用自成一体。定义 lists 使用的 URL，最简单的方法是复制现有的 urls.py：

$ cp superlists/urls.py lists/

然后把 superlists/urls.py 中的三行定义换成一个 include：

superlists/urls.py

from django.conf.urls import include, url
from lists import views as list_views  ➊
from lists import urls as list_urls  ➊
urlpatterns = [
    url(r'^$', list_views.home_page, name='home'),
    url(r'^lists/', include(list_urls)),  ➋
]

❶ 顺便使用 import x as y 句法为视图和 URL 映射创建别名。在顶层 urls.py 中，这是个好做法，便于从多个应用中引入视图和 URL 映射。其实，后文就会这么做。

❷ 这是那个 include。注意，include 可以使用一个正则表达式作为 URL 的前缀，这个前缀会添加到引入的所有 URL 前面（这就是去除重复的方法，同时也让代码结构更清晰）。

回到 lists/urls.py 中，我们只需写入那三个 URL 的后半部分，而且不用再写父级 urls.py 中的其他定义：

lists/urls.py(ch07l046)

from django.conf.urls import url
from lists import views
urlpatterns = [
    url(r'^new$', views.new_list, name='new_list'),
    url(r'^(\d+)/$', views.view_list, name='view_list'),
    url(r'^(\d+)/add_item$', views.add_item, name='add_item'),
]

再次运行单元测试，确认一切仍能正常运行。

我修改时，怀疑自己的能力，不确信能一次改对，所以特意一次只改一个 URL，防止测试失败。如果改错了，还有测试提醒我们。

你可以动手试一下。记得要改回来，而且要确认测试全部都能通过，然后再提交：

$ git status
$ git add lists/urls.py
$ git add superlists/urls.py
$ git diff --staged
$ git commit

终于结束了，这一章可真长啊。我们讨论了很多重要话题，先从测试隔离开始，然后又思考了设计。介绍了一些经验法则，比如“YAGNI”和“事不过三，三则重构”。最重要的是，看到了如何一步步修改现有网站，从一个可运行状态变成另一个可运行状态，逐渐实现新设计。

不得不说，我们的网站已经非常接近发布状态了，也就是说，这个待办事项清单网站的首个测试版可以公之于众了。不过，在此之前可能还要做些美化。在接下来的几章中，我们要介绍部署网站时需要做些什么。

更多 TDD 哲学

• 从一个可运行状态到另一个可运行状态（又叫测试山羊与重构猫）

  本能经常驱使我们直接动手一次修正所有问题，但如果不小心，最终可能像重构猫一样，改动了很多代码但都不起作用。测试山羊建议我们一次只迈一步，从一个可运行状态走到另一个可运行状态。

• 把工作分解成易于实现的小任务

  有时，我们要从“乏味的”工作入手，而不是直指有趣的任务。你要相信人只能活一次，平行宇宙中的另一个你可能过得并不好，把功能都破坏了，极尽所能想让应用再次运行起来。

• YAGNI

  “You ain't gonna need it”（你不需要这个）的简称，劝诫你不要受诱惑编写当时看起来可能有用的代码。很有可能你根本用不到这些代码，或者没有准确预见未来的需求。第 22 章给出了一种方法，可以让你避免落入这个陷阱。

第二部分　Web 开发要素

“真正的开发者一定会发布自己的产品。”

——Jeff Atwood

如果这是一本普通编程领域内的 TDD 入门书，到这里我们就可以庆贺一番了，毕竟我们已经掌握了扎实的 TDD 和 Django 基础，也具备了开始开发网站所需的一切知识。

但是，真正的开发者一定会发布自己的产品，那就无法回避 Web 开发中的一些棘手问题，比如静态文件、表单数据验证、可怕的 JavaScript 等，但最令人惧怕的还是部署到生产服务器。

在每个阶段，TDD 都能协助我们正确处理这些问题。

在这一部分中，我仍会尽量让学习曲线保持平缓，而且我们会学到多个重要的新概念和技术。我不会深入展开每个话题，只是希望我所演示的方法足够你在自己的项目中开始使用。如果真想在实际工作中使用这些技术，你还得做些扩展阅读。

如果你开始阅读本书之前并不熟悉 Django，现在花点时间读一遍 Django 官方教程，能很好地巩固目前所学的知识。熟悉 Django 的相关概念后，你会更自信，在接下来的几章中，能专注于我要讲的核心概念。

这一部分有很多有趣的知识，敬请期待！

第 8 章　美化网站：布局、样式及其测试方法

我们正考虑要发布网站的第一个版本，但让人尴尬的是，网站现在看起来还很简陋。本章介绍一些样式基础知识，包括如何集成 Bootstrap 这个 HTML/CSS 框架，还要学习 Django 处理静态文件的方式，以及如何测试静态文件。

8.1　如何在功能测试中测试布局和样式

不可否认，我们的网站现在没有太大的吸引力（如图 8-1）。

图 8-1：首页，有点简陋

　执行命令 manage.py runserver 启动开发服务器时，可能会看到一个数据库错误：“table lists_item has no column named list_id”（lists_item 表中没有名为 list_id 的列）。此时，需要执行 manage.py migrate 命令，更新本地数据库，让 models.py 中的改动生效。如果提醒 IntegrityErrors，就删除 1 数据库文件，然后再试。

1什么？删除数据库？疯了吗？并没有。在开发的过程中，本地开发数据库经常与迁移不同步，而且里面也没什么重要数据，因此可以放心删除。不过要谨慎对待生产服务器中的数据库，详情请参见附录 D。

既然不参加 Python 世界的选丑竞赛，就要美化这个网站。或许我们想实现如下效果。

• 一个精美且很大的输入框，用于新建清单，或者把待办事项添加到现有的清单中。
• 把这个输入框放在一个更大的居中框体中，吸引用户的注意力。

应该怎么使用 TDD 实现这些效果呢？大多数人都会告诉你，不要测试外观。他们是对的，这就像是测试常量一样毫无意义。

但可以测试装饰外观的方式，确信实现了预期的效果即可。例如，使用层叠样式表（Cascading Style Sheet，CSS）编写样式，样式表以静态文件的形式加载，而静态文件配置起来有点儿复杂（稍后会看到，把静态文件移到主机上，配置起来更麻烦），因此只需做某种“冒烟测试”（smoke test），确保加载了 CSS 即可。无须测试字体、颜色以及像素级位置，而是通过简单的测试，确认重要的输入框在每个页面中都按照预期的方式对齐，由此推断页面中的其他样式或许也都正确应用了。

先在功能测试中编写一个新测试方法：

functional_tests/tests.py (ch08l001)

class NewVisitorTest(LiveServerTestCase):
    [...]
    def test_layout_and_styling(self):
        # 伊迪丝访问首页
        self.browser.get(self.live_server_url)
        self.browser.set_window_size(1024, 768)
        # 她看到输入框完美地居中显示
        inputbox = self.browser.find_element_by_id('id_new_item')
        self.assertAlmostEqual(
            inputbox.location['x'] + inputbox.size['width'] / 2,
            512,
            delta=10
        )

这里有些新知识。先把浏览器的窗口设为固定大小，然后找到输入框元素，获取它的大小和位置，再做些数学计算，检查输入框是否位于网页的中线上。assertAlmostEqual 的作用是帮助处理舍入误差以及偶尔由滚动条等事物导致的异常，这里指定计算结果在正负 10 像素范围内为可接受。

运行功能测试会得到如下结果：

$ python manage.py test functional_tests
[...]
.F.
======================================================================
FAIL: test_layout_and_styling (functional_tests.tests.NewVisitorTest)
 ---------------------------------------------------------------------
Traceback (most recent call last):
  File "...superlists/functional_tests/tests.py", line 129, in
test_layout_and_styling
    delta=10
AssertionError: 107.0 != 512 within 10 delta
 
 ---------------------------------------------------------------------
Ran 3 tests in 9.188s
 
FAILED (failures=1)

这次失败在预料之中。不过，这种功能测试很容易出错，所以要用一种有点作弊的快捷方法确认输入框居中时功能测试能通过。一旦确认功能测试编写正确之后，就把这些代码删掉：

lists/templates/home.html (ch08l002)

<form method="POST" action="listsnew">
  <p style="text-align: center;">
    <input name="item_text" id="id_new_item" placeholder="Enter a to-do item" >
  <p>
  {% csrf_token %}
</form>

修改之后测试能通过，说明功能测试起作用了。下面扩展这个测试，确保新建清单后输入框仍然居中对齐显示：

functional_tests/tests.py (ch08l003)

# 她新建了一个清单，看到输入框仍完美地居中显示
inputbox.send_keys('testing')
inputbox.send_keys(Keys.ENTER)
self.wait_for_row_in_list_table('1: testing')
inputbox = self.browser.find_element_by_id('id_new_item')
self.assertAlmostEqual(
    inputbox.location['x'] + inputbox.size['width'] / 2,
    512,
    delta=10
)

这会导致测试再次失败：

  File "...superlists/functional_tests/tests.py", line 141, in
test_layout_and_styling
    delta=10
AssertionError: 107.0 != 512 within 10 delta

现在只提交功能测试：

$ git add functional_tests/tests.py
$ git commit -m "first steps of FT for layout + styling"

现在，似乎找到了满足需求的适当解决方案，能更好地样式化网站。那么就退回添加

$ git reset --hard

　git reset --hard 是一个破坏力极强的 Git 命令，它会还原所有没提交的改动，所以使用时要小心。它和几乎所有其他 Git 命令都不同，执行之后无法撤销操作。

8.2　使用CSS框架美化网站

设计不简单，现在更难，因为要处理手机、平板等设备。所以很多程序员，尤其是像我一样的懒人，都转而使用 CSS 框架解决问题。框架有很多，不过出现最早且最受欢迎的是 Twitter 开发的 Bootstrap。我们就使用这个框架。

Bootstrap 可在 http://getbootstrap.com/ 获取。

下载 Bootstrap，把它放在 lists 应用中一个新文件夹 static 里：2

2在 Windows 中不能使用 wget 和 unzip，但我相信你知道如何下载 Bootstrap，解压缩，再把 dist 文件夹中的内容移到 listsstaticbootstrap 文件夹中。

$ wget -O bootstrap.zip https://github.com/twbs/bootstrap/releasesdownload\
v3.3.4/bootstrap-3.3.4-dist.zip
$ unzip bootstrap.zip
$ mkdir lists/static
$ mv bootstrap-3.3.4-dist listsstaticbootstrap
$ rm bootstrap.zip

dist 文件夹中的内容是未经定制的原始 Bootstrap 框架，现在使用这些内容，但在真正的网站中不能这么做，因为用户能立即看出你使用 Bootstrap 时没有定制，业内人士也能由此推知你懒得为网站编写样式。你应该学习如何使用 LESS，至少把字体改了。Bootstrap 文档中有定制的详细说明，或者你可以阅读一篇名为“How to Customize Twitter's Bootstrap”的指南，写得还不错。

最终得到的 lists 文件夹结构如下：

$ tree lists
lists
├── __init__.py
├── __pycache__
│   └── [...]
├── admin.py
├── models.py
├── static
│   └── bootstrap
│       ├── css
│       │   ├── bootstrap.css
│       │   ├── bootstrap.css.map
│       │   ├── bootstrap.min.css
│       │   ├── bootstrap-theme.css
│       │   ├── bootstrap-theme.css.map
│       │   └── bootstrap-theme.min.css
│       ├── fonts
│       │   ├── glyphicons-halflings-regular.eot
│       │   ├── glyphicons-halflings-regular.svg
│       │   ├── glyphicons-halflings-regular.ttf
│       │   ├── glyphicons-halflings-regular.woff
│       │   └── glyphicons-halflings-regular.woff2
│       └── js
│           ├── bootstrap.js
│           ├── bootstrap.min.js
│           ├── npm.js
├── templates
│   ├── home.html
│   └── list.html
├── tests.py
├── urls.py
└── views.py

在 Bootstrap 文档中的“Getting Started”部分，你会发现 Bootstrap 要求 HTML 模板中包含如下代码：

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Bootstrap 101 Template</title>
    <!-- Bootstrap -->
    <link href="css/bootstrap.min.css" rel="stylesheet">
  </head>
  <body>
    <h1>Hello, world!</h1>
    <script src="http://code.jquery.com/jquery.js"></script>
    <script src="js/bootstrap.min.js"></script>
  </body>
</html>

我们已经有两个 HTML 模板了，所以不想在每个模板中都添加大量的样板代码。这似乎是运用“不要自我重复”原则的好时机，可以把通用代码放在一起。谢天谢地，Django 使用的模板语言可以轻易做到这一点，这种功能叫作“模板继承”。

8.3　Django模板继承

看一下 home.html 和 list.html 之间的差异：

$ diff lists/templates/home.html lists/templates/list.html
<     <h1>Start a new To-Do list</h1>
<     <form method="POST" action="listsnew">
---
>     <h1>Your To-Do list</h1>
>     <form method="POST" action="lists{{ list.id }}/add_item">
[...]
>     <table id="id_list_table">
>       {% for item in list.item_set.all %}
>         <tr><td>{{ forloop.counter }}: {{ item.text }}</td></tr>
>       {% endfor %}
>     </table>

这两个模板头部显示的文本不一样，而且表单的提交地址也不同。除此之外，list.html 还多了一个

现在我们弄清了两个模板之间共通以及有差异的地方，然后就可以让它们继承同一个父级模板了。先复制 home.html：

$ cp lists/templates/home.html lists/templates/base.html

把通用的样板代码写入这个基模板中，而且标记出各个“块”，块中的内容留给子模板定制：

lists/templates/base.html

<html>
  <head>
    <title>To-Do lists</title>
  </head>
  <body>
    <h1>{% block header_text %}{% endblock %}</h1>
    <form method="POST" action="{% block form_action %}{% endblock %}">
      <input name="item_text" id="id_new_item" placeholder="Enter a to-do item" >
      {% csrf_token %}
    <form>
    {% block table %}
    {% endblock %}
    </body>
</html>

基模板定义了多个叫作“块”的区域，其他模板可以在这些地方插入自己所需的内容。在实际操作中看一下这种机制的用法。修改 home.html，让它继承 base.html：

lists/templates/home.html

{% extends 'base.html' %}
{% block header_text %}Start a new To-Do list{% endblock %}
{% block form_action %}listsnew{% endblock %}

可以看出，很多 HTML 样板代码都不见了，只需集中精力编写想定制的部分。然后对 list.html 做同样的修改：

lists/templates/list.html

{% extends 'base.html' %}
{% block header_text %}Your To-Do list{% endblock %}
{% block form_action %}lists{{ list.id }}/add_item{% endblock %}
{% block table %}
  <table id="id_list_table">
    {% for item in list.item_set.all %}
      <tr><td>{{ forloop.counter }}: {{ item.text }}</td></tr>
    {% endfor %}
  </table>
{% endblock %}

对模板来说，这是一次重构。再次运行功能测试，确保没有破坏现有功能：

AssertionError: 107.0 != 512 within 10 delta

果然，结果和修改前一样。这次改动值得做一次提交：

$ git diff -b
# -b的意思是忽略空白，因为我们修改了HTML代码中的一些缩进，所以有必要使用这个旗标
$ git status
$ git add lists/templates # 先不添加static文件夹
$ git commit -m "refactor templates to use a base template"

8.4　集成Bootstrap

现在集成 Bootstrap 所需的样板代码更容易了，不过暂时不需要 JavaScript，只加入 CSS 即可：

lists/templates/base.html (ch08l006)

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>To-Do lists</title>
    <link href="css/bootstrap.min.css" rel="stylesheet">
  </head>
[...]

行和列

最后，使用 Bootstrap 中某些真正强大的功能。使用之前你得先阅读 Bootstrap 的文档。可以使用栅格系统和 text-center 类实现所需的效果：

lists/templates/base.html (ch08l007)

<body>
  <div class="container">
    <div class="row">
      <div class="col-md-6 col-md-offset-3">
        <div class="text-center">
          <h1>{% block header_text %}{% endblock %}</h1>
          <form method="POST" action="{% block form_action %}{% endblock %}">
            <input name="item_text" id="id_new_item"
                   placeholder="Enter a to-do item" >
            {% csrf_token %}
          <form>
        </div>
      </div>
    </div>
    <div class="row">
      <div class="col-md-6 col-md-offset-3">
        {% block table %}
        {% endblock %}
      </div>
    </div>
  </div>
</body>

（如果你从来没有把一个 HTML 标签分成多行，可能会觉得上述 标签有点儿打破常规。这样写完全可行，如果你不喜欢，可以不这么写。）

　如果你从未看过 Bootstrap 文档，花点儿时间浏览一下吧。文档中介绍了很多有用的工具，可以运用到你的网站中。

做了上述修改之后，功能测试能通过吗？

AssertionError: 107.0 != 512 within 10 delta

嗯，还不能。为什么没有加载 CSS 呢？

8.5　Django中的静态文件

Django 处理静态文件时需要知道两件事（其实所有 Web 服务器都是如此）。

(1) 收到指向某个 URL 的请求时，如何区分请求的是静态文件，还是需要经过视图函数处理，生成 HTML。

(2) 到哪里去找用户请求的静态文件。

其实，静态文件就是把 URL 映射到硬盘中的文件上。

为了解决第一个问题，Django 允许我们定义一个 URL 前缀，任何以这个前缀开头的 URL 都被视作针对静态文件的请求。默认的前缀是 static，在 settings.py 中定义：

superlists/settings.py

[...]
# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/1.11/howto/staticfiles/
STATIC_URL = 'static'

后面在这一部分添加的设置都和第二个问题有关，即在硬盘中找到真正的静态文件。

既然用的是 Django 开发服务器（manage.py runserver），就可以把寻找静态文件的任务交给 Django 完成。Django 会在各应用中每个名为 static 的子文件夹里寻找静态文件。

现在知道把 Bootstrap 框架的所有静态文件都放在 lists/static 文件夹中的原因了吧。可是为什么现在不起作用呢？因为没在 URL 中加入前缀 static。再看一下 base.html 中链接 CSS 的元素：

<link href="css/bootstrap.min.css" rel="stylesheet">

若想让这行代码起作用，要把它改成：

lists/templates/base.html

<link href="staticbootstrap/css/bootstrap.min.css" rel="stylesheet">

现在，开发服务器收到这个请求时就知道请求的是静态文件，因为 URL 以 static 开头。然后，服务器在每个应用中名为 static 的子文件夹里搜寻名为 bootstrap/css/bootstrap.min.css 的文件。最后找到的文件应该是 listsstaticbootstrap/css/bootstrap.min.css。

如果手动在浏览器中查看，应该会看到样式起作用了，如图 8-2 所示。

图 8-2：网站开始变得有点好看了

换用StaticLiveServerTestCase

不过，功能测试还无法通过：

AssertionError: 107.0 != 512 within 10 delta

这是因为，虽然 runserver 启动的开发服务器能自动找到静态文件，但 LiveServerTestCase 找不到。不过无须担心，Django　为开发者提供了一个更神奇的测试类，叫 StaticLiveServerTestCase。

下面换用这个测试类：

functional_tests/tests.py

@@ -1,14 +1,14 @@
-from django.test import LiveServerTestCase
+from django.contrib.staticfiles.testing import StaticLiveServerTestCase
  from selenium import webdriver
  from selenium.common.exceptions import WebDriverException
  from selenium.webdriver.common.keys import Keys
  import time
  MAX_WAIT = 10
-class NewVisitorTest(LiveServerTestCase):
+class NewVisitorTest(StaticLiveServerTestCase):
     def setUp(self):

现在测试能找到 CSS 了，因此测试也能通过了：

$ python manage.py test functional_tests
Creating test database for alias 'default'...
...
 ---------------------------------------------------------------------
Ran 3 tests in 9.764s

　Windows 用户在这里可能会看到一些错误消息（无关紧要，但容易让人分心）：socket.error: [WinError 10054] An existing connection was forcibly closed by the remote host（现有连接被远程主机强制关闭）。在 tearDown 方法的 self.browser.quit() 之前加上 self.browser.refresh() 就能去掉这些错误。Django 的追踪系统正在关注这个问题。

太好了！

8.6　使用Bootstrap中的组件改进网站外观

看一下使用 Bootstrap 百宝箱中的其他工具能否进一步改善网站的外观。

8.6.1　超大文本块

Bootstrap 中有个类叫 jumbotron，用于特别突出地显示页面中的元素。使用这个类放大显示页面的主头部和输入表单：

lists/templates/base.html (ch08l009)

    <div class="col-md-6 col-md-offset-3 jumbotron">
      <div class="text-center">
        <h1>{% block header_text %}{% endblock %}</h1>
        <form method="POST" action="{% block form_action %}{% endblock %}">
          [...]

　调整网页的设计和布局时，可以打开一个浏览器窗口，时不时地刷新页面。执行 python manage.py runserver 命令启动开发服务器，然后在浏览器中访问 http://localhost:8000，边改边看效果。

8.6.2　大型输入框

超大文本块是个好的开始，不过和其他内容相比，输入框显得太小。幸好 Bootstrap 为表单控件提供了一个类，可以把输入框变大：

lists/templates/base.html (ch08l010)

    <input name="item_text" id="id_new_item"
           class="form-control input-lg"
           placeholder="Enter a to-do item" />

8.6.3　样式化表格

现在表格中的文字和页面中的其他文字相比也很小，加上 Bootstrap 提供的 table 类可以改进显示效果：

lists/templates/list.html (ch08l011)

    <table id="id_list_table" class="table">

8.7　使用自己编写的CSS

最后，我想让输入表单离标题文字远一点儿。Bootstrap 没有提供现成的解决方案，那么就自己实现吧，引入一个自己编写的 CSS 文件：

lists/templates/base.html

    [...]
      <title>To-Do lists</title>
      <link href="staticbootstrap/css/bootstrap.min.css" rel="stylesheet">
      <link href="staticbase.css" rel="stylesheet">
    </head>

新建文件 listsstaticbase.css，写入自己编写的 CSS 新规则。使用输入框的 id（id_new_item）定位元素，然后为其编写样式：

listsstaticbase.css

#id_new_item {
    margin-top: 2ex;
}

虽然要多操作几步，不过效果很让我满意（如图 8-3）。

图 8-3：清单页面，各部分都显示得很大

如果想进一步定制 Bootstrap，需要编译 LESS。我强烈推荐你花时间定制，总有一天你会有这种需求。LESS、Sass 等其他伪 CSS 类工具，对普通的 CSS 做了很大改进，即便不使用 Bootstrap 也很有用。我不会在这本书中介绍 LESS，网上有很多参考资料，比如说“How to Customize Twitter's Bootstrap”。

最后再运行一次功能测试，看一切是否仍能正常运行：

$ python manage.py test functional_tests
[...]
...
 ---------------------------------------------------------------------
Ran 3 tests in 10.084s
 
OK

样式化暂告段落。现在是提交的绝好时机：

$ git status # 修改了tests.py、base.html和list.html，未跟踪lists/static
$ git add .
$ git status # 会显示添加了所有Bootstrap相关文件
$ git commit -m "Use Bootstrap to improve layout"

8.8　补遗：collectstatic命令和其他静态目录

前文说过，Django 的开发服务器会自动在应用的文件夹中查找并呈现静态文件。在开发过程中这种功能不错，但在真正的 Web 服务器中，并不需要让 Django 伺服静态内容，因为使用 Python 伺服原始文件速度慢而且效率低，Apache、Nginx 等 Web 服务器能更好地完成这项任务。或许你还会决定把所有静态文件都上传到 CDN（Content Distribution Network，内容分发网络），不放在自己的主机中。

鉴于此，要把分散在各个应用文件夹中的所有静态文件集中起来，复制一份放在一个位置，为部署做好准备。collectstatic 命令的作用就是完成这项操作。

静态文件集中放置的位置由 settings.py 中的 STATIC_ROOT 定义。下一章会做些部署工作，现在就试着设置一下吧。把 STATIC_ROOT 的值设为仓库之外的一个文件夹——我要使用和主源码文件夹同级的一个文件夹：

workspace
│    ├── superlists
│    │    ├── lists
│    │    │     ├── models.py
│    │    │
│    │    ├── manage.py
│    │    ├── superlists
│    │
│    ├── static
│    │    ├── base.css
│    │    ├── etc...

关键在于，静态文件所在的文件夹不能放在仓库中——不想把这个文件夹纳入版本控制，因为其中的文件和 lists/static 中的一样。

下面是指定这个文件夹位置的一种优雅方式，路径相对 settings.py 文件而言：

superlists/settings.py (ch08l018)

# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/1.11/howto/staticfiles/
STATIC_URL = 'static'
STATIC_ROOT = os.path.abspath(os.path.join(BASE_DIR, '../static'))

在设置文件的顶部，你会看到定义了 BASE_DIR 变量。这个变量利用 __file__ （这是 Python 内置的变量，特别有用），为我们提供了很大的便利。

下面执行 collectstatic 命令试试：

$ python manage.py collectstatic
[...]
Copying '...superlistslistsstatic/bootstrap/css/bootstrap-theme.css'
Copying '...superlistslistsstatic/bootstrap/css/bootstrap.min.css'
 
76 static files copied to '...static'.

如果查看 ../static，会看到所有的 CSS 文件：

$ tree ..static
..static
├── admin
│   ├── css
│   │   ├── base.css
 
[...]
 
│                  └── xregexp.min.js
├── base.css
└── bootstrap
    ├── css
    │   ├── bootstrap.css
    │   ├── bootstrap.css.map
    │   ├── bootstrap.min.css
    │   ├── bootstrap-theme.css
    │   ├── bootstrap-theme.css.map
    │   └── bootstrap-theme.min.css
    ├── fonts
    │   ├── glyphicons-halflings-regular.eot
    │   ├── glyphicons-halflings-regular.svg
    │   ├── glyphicons-halflings-regular.ttf
    │   ├── glyphicons-halflings-regular.woff
    │   └── glyphicons-halflings-regular.woff2
    └── js
        ├── bootstrap.js
        ├── bootstrap.min.js
        └── npm.js
 
 
14 directories, 76 files

collectstatic 命令还收集了管理后台的所有 CSS 文件。管理后台是 Django 的强大功能之一，总有一天我们要知道它的全部功能。但现在还不准备用，所以暂且禁用：

superlists/settings.py

INSTALLED_APPS = [
    #'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'lists',
]

然后再执行 collectstatic 试试：

$ rm -rf ..static
$ python manage.py collectstatic --noinput
Copying '...superlistslistsstatic/base.css'
[...]
Copying '...superlistslistsstatic/bootstrap/css/bootstrap-theme.css'
Copying '...superlistslistsstatic/bootstrap/css/bootstrap.min.css'
 
15 static files copied to '...static'.

好多了。

总之，现在知道了怎么把所有静态文件都聚集到一个文件夹中，这样 Web 服务器就能轻易找到静态文件。下一章会深入介绍这个功能和测试方法。

现在，先提交 settings.py 中的改动：

$ git diff # 会看到settings.py中的改动
$ git commit -am "set STATIC_ROOT in settings and disable admin"

8.9　没谈到的话题

本章只简单介绍了样式化和 CSS，有一些话题我本想涉及，但没做到。你可以进一步研究以下话题。

• 使用 LESS 或 Sass 定制 Bootstrap。
• 使用 {% static %} 模板标签，这样做更符合 DRY 原则，也不用硬编码 URL。
• 客户端打包工具，例如 npm 和 bower。

总结：如何测试设计和布局

简单来说，不应该为设计和布局编写测试。因为这太像是测试常量，所以写出的测试不太牢靠。

这说明设计和布局的实现过程极具技巧性，涉及 CSS 和静态文件。因此，可以编写一些简单的“冒烟测试”，确认静态文件和 CSS 起作用即可。下一章我们会看到，把代码部署到生产环境时，冒烟测试能协助我们发现问题。

但是，如果某部分样式需要很多客户端 JavaScript 代码才能使用（我花了很多时间实现动态缩放），就必须为此编写一些测试。

要试着编写最简的测试，确信设计和布局能起作用即可，不必测试具体的实现。我们的目标是能自由修改设计和布局，且无须时不时地调整测试。

第 9 章　使用过渡网站测试部署

“所有乐趣都在部署到生产环境之前。”

——Devops Borat

是时候发布网站的首个版本让公众使用了。人们常说，如果等到一切就绪再发布，等待的时间就太长了。

我们的网站有用吗？是不是比没有要好？能在这个网站上创建待办事项清单吗？这三个疑问的答案都是肯定的。

可是，现在还无法登录，也无法把任务标记为已完成。不过你真的需要这些功能吗？不一定，因为你永远也不知道用户真正想使用你的网站做什么。我们觉得用户应该想使用这个网站制定待办事项清单，但他们真正想编写的或许是一个“十佳假蝇钓鱼地”列表，因此就不用提供“标记为已完成”功能。在发布之前，我们永远不知道用户的真实需求。

本章会详细介绍如何把网站部署到真实的线上 Web 服务器中。

你可能想跳过这一章，因为本章有很多令人生畏的知识，或许还觉得部署不是你阅读本书的初衷。但是我强烈建议你读一下。本章是我最满意的内容之一，而且有很多读者写信说很庆幸自己当时克服困难读完了这一章。

如果你以前从未把网站部署到服务器上，读过本章后会发现一片新大陆，而且没有什么能比看到自己的网站在真正的互联网中上线更令人满足的了。如果你还迟疑，现今流行的术语，比如“开发运维”（DevOps），一定能让你相信，花时间学习部署是值得的。

　你的网站上线后请写封信告诉我网址。收到这样的来信，我的心里总是感觉暖暖的。我的电子邮件地址是 obeythetestinggoat@gmail.com。

9.1　TDD以及部署的危险区域

把网站部署到线上 Web 服务器是个很复杂的过程。我们经常会听到这样凄苦的抱怨：“但在我的设备中可以正常运行啊！”

部署过程中的一些危险区域如下。

• 静态文件（CSS、JavaScript、图片等）

Web 服务器往往需要特殊的配置才能伺服静态文件。

• 数据库

可能会遇到权限和路径问题，还要小心处理，在多次部署之间不能丢失数据。

• 依赖

要保证服务器上安装了网站依赖的包，而且版本要正确。

不过这些问题都有相应的解决方案。下面一一说明。

• 使用与生产环境一样的基础架构部署过渡网站（staging site），这么做可以测试部署的过程，确保部署真正的网站时操作正确。
• 可以在过渡网站中运行功能测试，确保服务器中安装了正确的代码和依赖包。而且为了测试网站的布局，我们编写了冒烟测试，这样就能知道是否正确加载了 CSS。
• 与在本地设备上一样，当服务器上运行多个 Python 应用时，可以使用虚拟环境管理包和依赖。
• 最后，一切操作都自动化完成。使用自动化脚本部署新版本，使用同一个脚本把网站部署到过渡环境和生产环境，这么做能尽量保证过渡网站和线上网站一样。 1

1我称之为“过渡”服务器，有人叫它“开发”服务器，还有人叫它“预备生产”服务器。不管叫什么，目的都是架设一个尽量和生产服务器一样的环境来测试代码。

在接下来的几页中，我会详细说明一个部署过程。这不是最佳的部署过程，所以别把它当作最佳实践，也别当作是推荐做法。只是做个演示，告诉你部署过程涉及哪些问题，以及测试在这个过程中的作用。

内容提要

接下来的三章内容很多，这里列出提要，帮助你理清思路。

本章：搭建基础环境

• 修改功能测试，以便在过渡服务器中运行。
• 架设服务器，安装所需的全部软件，再把过渡和线上环境使用的域名指向这个服务器。
• 使用 Git 把代码上传到服务器。
• 使用 Django 开发服务器在过渡环境的域名下尝试运行过渡网站。
• 自己动手在服务器上搭建虚拟环境（不用 virtualenvwrapper），确保数据库和静态文件都能使用。
• 在这个过程中不断运行功能测试，找出哪些功能可以正常运行，哪些不能。

下一章：针对生产环境配置

• 修改配置，使其适应生产环境：不再使用 Django 开发服务器，让应用在引导时自动启动，把 DEBUG 设为 False，等等。

关于部署的第三章：自动部署

(1) 配置好之后，编写一个脚本，自动执行前面手动完成的操作，这样以后就能自动部署网站了。

(2) 最后，使用自动化脚本把网站的生产版本部署到真正的域名下。

9.2　一如既往，先写测试

稍微修改一下功能测试，让它能在过渡网站中运行。添加一个参数，指定测试所用的临时服务器地址：

functional_tests/tests.py (ch08l001)

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

还记得我说过 LiveServerTestCase 有一定的缺陷吗？其中一个缺陷是，它总是假定你想使用它自己的测试服务器，这个服务器的地址通过 self.live_server_url 获取。有时我确实想使用这个测试服务器，但也想有别的选择，比如使用一个真正的服务器。

❶ 我通过环境变量 STAGING_SERVER 决定使用哪个服务器。

❷ 我采用的措施是，把 self.live_server_url 替换成“真实”服务器的地址。

按照“常规的”方式运行功能测试，确保上述改动没有破坏现有功能：

$ python manage.py test functional_tests
[...]
Ran 3 tests in 8.544s
 
OK

然后指定过渡服务器的 URL 再运行试试。我要使用的过渡服务器地址是 superlists-staging.ottg.eu：

$ STAGING_SERVER=superlists-staging.ottg.eu python manage.py test functional_tests
 
======================================================================
FAIL: test_can_start_a_list_for_one_user
(functional_tests.tests.NewVisitorTest)
 ---------------------------------------------------------------------
Traceback (most recent call last):
  File "...superlists/functional_tests/tests.py", line 49, in
test_can_start_a_list_and_retrieve_it_later
    self.assertIn('To-Do', self.browser.title)
AssertionError: 'To-Do' not found in 'Domain name registration | Domain names
| Web Hosting | 123-reg'
[...]
 
======================================================================
FAIL: test_multiple_users_can_start_lists_at_different_urls
(functional_tests.tests.NewVisitorTest)
 ---------------------------------------------------------------------
Traceback (most recent call last):
  File
"...superlists/functional_tests/tests.py", line 86, in
test_layout_and_styling
    inputbox = self.browser.find_element_by_id('id_new_item')
[...]
selenium.common.exceptions.NoSuchElementException: Message: Unable to locate
element: [id="id_new_item"]
[...]
 
======================================================================
FAIL: test_layout_and_styling (functional_tests.tests.NewVisitorTest)
 ---------------------------------------------------------------------
Traceback (most recent call last):
  File
[...]
selenium.common.exceptions.NoSuchElementException: Message: Unable to locate
element: [id="id_new_item"]
[...]
 
Ran 3 tests in 19.480s:
 
FAILED (failures=3)

　如果在 Windows 上看到“STAGING_SERVER is not recognized as a command”这样的错误，可能是因为你没使用 Git-Bash。请再看一下“准备工作和应具备的知识”。

可以看到，和预期一样，两个测试都失败了，因为我还没有域名呢。实际上，从第一个调用跟踪中可以看出，访问域名注册商的网站首页时测试就失败了。

不过，看起来功能测试的测试对象是正确的，所以做一次提交吧：

$ git diff # 会显示functional_tests.py中的改动
$ git commit -am "Hack FT runner to be able to test staging"

　别使用 export 设定 STAGING_SERVER 环境变量，否则在当前终端里运行的后续测试都会在过渡网站中运行（如果这跟你的预期不一样，会让你十分困惑）。最好在每次运行功能测试时明确设定。

9.3　注册域名

读到这里，我们需要注册几个域名，不过也可以使用同一个域名下的多个二级域名。我要使用的域名是 superlists.ottg.eu 和 superlists-staging.ottg.eu。如果你还没有域名，现在就得注册一个。再次说明，我真的希望你按我所说的做。如果你从未注册过域名，随便选一个老牌注册商买一个便宜的就行，只要花 5 美元左右，甚至还能找到免费域名。我说过想在真正的网站中看到你的应用，这或许能推动你去注册一个域名。

9.4　手动配置托管网站的服务器

可以把部署的过程分成两个任务。

• 配置新服务器，用于托管代码。
• 把新版代码部署到配置好的服务器中。

有些人喜欢每次部署都用全新服务器，我们在 PythonAnywhere 就是这么做的。不过这种做法只适用于大型的复杂网站，或者对现有网站做了重大修改。对我们这个简单的网站来说，分别完成上述两个任务更合理。虽然最终这两个任务都要完全自动化，但就目前而言或许更适合手动配置。

在阅读过程中，你要记住，配置的过程各异，因此部署有很多通用的最佳实践。所以，与其尝试记住我的具体做法，不如试着理解其中的基本原理，这样以后你遇到具体问题时就能使用相同的思想解决了。

9.4.1　选择在哪里托管网站

现今，托管网站有大量不同的方案，不过基本上可以归纳为两类。

• 运行自己的服务器（可能是虚拟服务器）。
• 使用“平台即服务”（Platform-As-A-Service，PaaS）提供商，例如 Heroku、OpenShift 或 PythonAnywhere。

对小型网站而言，PaaS 的优势尤其明显，我强烈建议你考虑使用 PaaS。不过，基于几个原因，本书不会使用 PaaS。首先，有利益冲突，我觉得 PythonAnywhere 是最棒的，但我这么说是因为我在这家公司工作。其实，各家 Paas 提供商提供的支持各不相同，部署的过程也不一样，所以学会其中一家的部署方法并不能在别家使用。任何一家提供商都有可能完全修改部署过程，或者当你阅读这本书时已经停业了。

因此，我们要学习一些优秀的老式服务器管理方法，包括 SSH 和 Web 服务器配置。这些方法永远不会过时，而且学会这些方法还能从头发花白的老前辈那儿得到一些尊重。

我要试着搭建一个十分类似于 PaaS 环境的服务器，不管以后你选择哪种配置方案，都能用到这个部署过程中学到的知识。

9.4.2　搭建服务器

我不规定你该怎么搭建服务器，不管你选择使用 Amazon AWS、Rackspace 或 Digital Ocean，还是自己的数据中心里的服务器，抑或楼梯后橱柜里的 Raspberry Pi——哪种方案都行，只要满足以下条件即可。

• 服务器的系统使用 Ubuntu16.04（“Xenial/LTS”）。
• 有访问服务器的 root 权限。
• 外网可访问。
• 可以通过 SSH 登录。

我推荐使用 Ubuntu 发行版是因为其中安装了 Python 3.6，而且有一些配置 Nginx 的特殊方式（后文会用到）。如果你知道自己在做什么，或许可以换用其他发行版，但遇到问题只能靠自己了。

如果你从未用过 Linux 服务器，完全不知道从何处入手，可以参照我在 GitHub 上写的一篇简要指南（https://github.com/hjwp/Book-TDD-Web-Dev-Python/blob/master/server-quickstart.md）。

　有些人阅读本章时会跳过购买域名和架设真正的服务器这两部分，直接在自己的电脑中使用虚拟机。请不要这么做，这两种方式不一样。配置服务器本身已经很复杂了，如果用虚拟机，阅读本章的内容时会遇到更大的困难。如果你担心要花钱，可以四处找找，域名和服务器都有免费的。如果需要进一步指导，可以给我发电子邮件，我一直都乐于助人。

9.4.3　用户账户、SSH和权限

本节假定你的用户账户没有 root 权限，但有使用 sudo 的权限，因此执行需要 root 权限的操作时，我们可以使用 sudo。在下面的说明中，如果需要用 sudo，我会指出来。

我使用的用户名是“elspeth”，你可以根据自己的喜好起名。

9.4.4　安装Nginx

我们需要一个 Web 服务器，既然现在酷小孩都使用 Nginx，那我们也用它吧。我和 Apache 斗争了多年，可以说单就配置文件的可读性这一项而言，Nginx 如同神赐般拯救了我们。

在我的服务器中安装 Nginx 只需执行一次 apt-get 命令即可，然后再执行一个命令就能看到 Nginx 默认的欢迎页面：

elspeth@server:$ sudo apt-get install nginx
elspeth@server:$ sudo systemctl start nginx

（你可能要先执行 apt-get update 和 / 或 apt-get upgrade。）

　注意本章命令行代码清单中的 elspeth@server，它表示命令必须在服务器中执行，而不是在你自己的电脑中执行。

现在访问服务器的 IP 地址就能看到 Nginx 的“Welcome to nginx”（欢迎使用 Nginx）页面，如图 9-1 所示。

图 9-1：Nginx 可用了

　如果没看到这个页面，可能是因为防火墙没有开放 80 端口。以 AWS 为例，你可能得配置服务器的“Security Group”才能打开 80 端口。

9.4.5　安装Python 3.6

写作本书时，Ubuntu 的标准仓库中还没有 Python 3.6，但是用户贡献的“Deadsnakes PPA”中有。

既然我们有 root 权限，下面就来安装所需的系统级关键软件：Python、Git、pip 和 virtualenv。

elspeth@server:$ sudo add-apt-repository ppa:fkrull/deadsnakes
elspeth@server:$ sudo apt-get update
elspeth@server:$ sudo apt-get install python3.6 python3.6-venv

顺便把 Git 也安装上：

elspeth@server:$ sudo apt-get install git

9.4.6　解析过渡环境和线上环境所用的域名

不想总是使用 IP 地址，所以要把过渡环境和线上环境所用的域名解析到服务器上。我的注册商提供的控制面板如图 9-2 所示。

图 9-2：解析域名

在 DNS 系统中，把域名指向一个确切的 IP 地址叫作“A 记录”。各注册商提供的界面有所不同，但在你的注册商网站中四处点击几次应该就能找到正确的页面。

9.4.7　使用功能测试确认域名可用而且Nginx正在运行

为了确认一切顺利，可以再次运行功能测试。你会发现失败消息稍微有点儿不同，其中一个消息和 Nginx 有关：

$ STAGING_SERVER=superlists-staging.ottg.eu python manage.py test functional_tests
[...]
selenium.common.exceptions.NoSuchElementException: Message: Unable to locate
element: [id="id_new_item"]
[...]
AssertionError: 'To-Do' not found in 'Welcome to nginx!'

有进展。鼓励一下自己，你可以泡杯茶，吃块巧克力饼干。

9.5　手动部署代码

接着要让过渡网站运行起来，检查 Nginx 和 Django 之间能否通信。从这一步起，配置结束了，进入“部署”阶段。在部署的过程中，要思考如何自动化这些操作。

　区分配置阶段和部署阶段有个经验法则：配置时需要 root 权限，但部署时不需要。

需要一个文件夹来存放源码。我们把这个目录放在一个非 root 用户的家目录中，在我的服务器中，路径是 homeelspeth（好像所有共享主机的系统都是这么设置的。不论使用什么主机，一定要以非 root 用户身份运行 Web 应用）。我要按照下面的文件结构存放网站的代码：

homeelspeth
├── sites
│   ├── www.live.my-website.com
│   │    ├── database
│   │    │     └── db.sqlite3
│   │    ├── source
│   │    │    ├── manage.py
│   │    │    ├── superlists
│   │    │    ├── etc...
│   │    │
│   │    ├── static
│   │    │    ├── base.css
│   │    │    ├── etc...
│   │    │
│   │    └── virtualenv
│   │          ├── lib
│   │          ├── etc...
│   │
│   ├── www.staging.my-website.com
│   │    ├── database
│   │    ├── etc...

每个网站（过渡网站，线上网站或其他网站）都放在各自的文件夹中。在各文件夹中又有单独的子文件夹，分别存放源码、数据库和静态文件。采用这种结构的逻辑依据是，不同版本的网站源码可能会变，但数据库始终不变。静态文件夹也在同一个相对位置，即 ../static，前一章末尾我们已经设置好了。最后，virtualenv 也有自己的子文件夹（在服务器上无须使用 virtualenvwrapper，我们将动手创建虚拟环境）。

9.5.1　调整数据库的位置

首先，在 settings.py 中修改数据库的位置，而且要保证修改后的位置在本地电脑中也能使用：

superlists/settings.py (ch08l003)

# 项目内的路径使用os.path.join(BASE_DIR, ...)形式构建
import os
BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
[...]
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, '../database/db.sqlite3'),
    }
}

　看一下 settings.py 文件顶部 BASE_DIR 的定义。注意，最内层是 abspath。处理路径时一定要这么做，否则导入文件时会遇到各种奇怪的问题。感谢 Green Nathan 指出这一点。

在本地试一下：

$ mkdir ../database
$ python manage.py migrate --noinput
Operations to perform:
Apply all migrations: auth, contenttypes, lists, sessions
Running migrations:
[...]
$ ls ../database/
db.sqlite3

看起来可以正常使用。做次提交：

$ git diff # 会看到settings.py中的改动
$ git commit -am "move sqlite database outside of main source tree"

借助代码分享网站，使用 Git 把代码上传到服务器。如果之前没推送，现在要把代码推送到 GitHub、BitBucket 或同类网站中。这些网站都为初学者提供了很好的用法说明，告诉你该怎么推送。

把源码上传到服务器所需的全部 Bash 命令如下所示。如果你不熟悉 Bash 命令，我告诉你，export 的作用是创建一个可在 bash 中使用的“本地变量”：

elspeth@server:$ export SITENAME=superlists-staging.ottg.eu
elspeth@server:$ mkdir -p ~/sites/$SITENAME/database
elspeth@server:$ mkdir -p ~/sites/$SITENAME/static
elspeth@server:$ mkdir -p ~/sites/$SITENAME/virtualenv
# 要把下面这行命令中的URL换成你自己仓库的URL
elspeth@server:$ git clone https://github.com/hjwp/bookexample.git \
~/sites/$SITENAME/source
Resolving deltas: 100% [...]

　使用 export 定义的 Bash 变量只在当前终端会话中有效。如果退出服务器后再登录，就需要重新定义。这个特性有点隐晦，因为 Bash 不会报错，而是直接用空字符串表示未定义的变量，这种处理方式会导致诡异的结果。如果不信，可以执行 echo $SITENAME 试试。

现在网站安装好了，在开发服务器中运行试试——这是一个冒烟测试，检查所有活动部件是否连接起来了：

elspeth@server:$ $ cd ~/sites/$SITENAME/source
$ python manage.py runserver
Traceback (most recent call last):
  File "manage.py", line 8, in <module>
    from django.core.management import execute_from_command_line
ImportError: No module named django.core.management