Python测试驱动开发实践, 3rd Edition

第三章. 使用单元测试测试 简单主页 使用单元测试

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

上一章结束时功能测试（FT）失败， 提示网站首页标题需包含“待办事项”。 现在开始着手开发应用程序。 本章将创建首个HTML页面，了解URL处理机制， 并使用Django视图函数生成HTTP请求响应。

警告：即将进入实战阶段

前两章刻意保持轻松简洁。从此刻起，我们将深入实质性编程。在此预告：后续必将遭遇问题——你看到的结果可能与预期不符。这实属好事，因为这将是一次真正的"磨炼性格的学习体验™"。

一种可能是我的说明不够明确，导致你 执行了与我预期不同的操作。请退一步思考： 当前章节的目标是什么？我们正在编辑哪个文件？ 希望用户能实现什么功能？测试内容及其目的为何？ 或许你编辑了错误的文件或函数， 或是运行了错误的测试。 我认为，这些"停下来思考"的时刻能让你学到比照着说明顺利复制粘贴时更多的TDD知识。

也可能是真实的缺陷。请保持耐心，仔细研读错误信息（参见"解读追溯信息"）， 终将找到症结所在。 问题往往只是漏个逗号、多个斜杠，或Selenium查找方法里少个s。但正如Zed Shaw在《硬核学Python》中强调的：调试本身就是学习过程中不可或缺的环节，所以请坚持下去！ 若遇到真正棘手的问题，随时欢迎发邮件咨询。祝调试愉快！

我们的首个Django应用与单元测试

Django鼓励将代码结构化为应用程序。 理论上一个项目可包含多个应用程序； 你可以使用他人开发的第三方应用程序， 甚至可能在不同项目中复用自己的应用程序...​虽然 我必须承认，我自己从未真正实现过后者！ 但应用程序仍是保持代码条理性的好方法。

现在开始创建待办事项应用：

$ python manage.py startapp lists

这将在manage.py和现有superlists文件夹旁创建名为lists的文件夹， 其中包含若干占位文件，用于存放模型、视图等组件， 以及我们当前最关心的测试文件：

.
├── db.sqlite3
├── functional_tests.py
├── lists
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── migrations
│   │   └── __init__.py
│   ├── models.py
│   ├── tests.py
│   └── views.py
├── manage.py
└── superlists
    ├── __init__.py
    ├── asgi.py
    ├── settings.py
    ├── urls.py
    └── wsgi.py

单元测试与功能测试的区别

如同我们给事物贴上的许多标签， 单元测试与功能测试的界限有时会变得模糊。 但基本区别在于： 功能测试从外部视角检验应用程序，即用户视角； 而单元测试则从内部视角检验应用程序，即程序员视角。

我演示的TDD方法同时运用这两类测试 来驱动应用程序的开发并确保其正确性。 我们的工作流程大致如下：

1. 我们首先编写功能测试，从用户视角描述新功能的典型用例。

2. 当功能测试失败时， 我们开始思考如何编写代码使其通过 （或至少绕过当前失败点）。 此时我们通过一个或多个单元测试定义 代码的行为规范——核心理念是 每行生产代码都应由（至少）一个单元测试覆盖。

3. 当单元测试失败时， 我们编写最小量的应用程序代码 ...