#Django 测试指南
对绝大部分人来说，测试Django应用感觉很神秘，他们只是听说代码必须要测试，但是经常找不到线索如何入手。当他们看了Django的测试文档，他们找到深入的哪些功能是可用的，但是如果实现没有任何指导。
这是本博客系列的第一篇，尝试帮助大家减轻压力，使得每个人在测试潮流。假设你从来没有做过任何测试，但是对Python&Django很熟悉了。
我们将贯穿添加测试到perennial 教程，为了更好的关注，我上传了代码到Github，标签有主要的步骤显示代码是如何改变的。
在我们深入代码前，我们先介绍一些基本的概念，讨论如何think/go 关于测试。
####为什么必须要测试代码
Code without tests is broken by design --jacob
为代码提供自动化测试是重复确定最小化开发者努力，你写的代码处理任务.我喜欢特车作为我的保险策略。他们经常能让我远离破坏已存在的代码。再去看看其他愚蠢额人们，他们同样证明代码工作正确。没有证明，你有得是一堆代码工作起来正确，一旦你的机器你又要手工测试一遍又一遍在将来。
当你第一次开始，谢测试是一个提心吊胆的任务，听起来就象是额外的工作。但是简单测试非常易于编写，有一些测试总比没有测试好。你添加的新的测试后，你的套件货跟着增长。
这不是说有了测试后就能解决任何问题，软件中bug总是有的，也是测试忽略了代码深度或者用户将使用一些意外之事的方法，不是测试给你信心，一个安全的网络。
####测试的种类 有很多种不同的测试类型，比较突出的在这个系类中将涵盖 但愿测试 和 几层测试 。
单元测试 覆盖面非常小，高度专一域的代码。通常相关作用和其他域的软件。这个风格的测试在危机的时候非常有帮助，复杂的组件，例如验证，倒入或者方法复杂的业务逻辑。
继承测试 这种测试通常覆盖很多不同的面使得应用工作一起产生一个结果，他们确保数据流失正确的，经常处理多个用户交互。
这两种方式主要的不同不是工具而是方法，你选择哪种去测试。非常普遍是事混合交叉使用适度的。
#####工具
在Python世界里，有各式各样的工具去测试你的代码，一些主流的可选项包括：
- unittest/unittest2
- doctest
- nose 这份指南不会深入doctests和nose测试，坚持unittest，这是因为用uninitest写测试运行更快当你在测试Django应用的时候（感谢一些有趣的）。我鼓励你去投资其他选项，只要扩展你的知识。
你应该不会疑惑 uniitest（库）用于单元测试（连续代码块小测试的方法），你通常使用unittest库用于单元测试和集成测试。
####什么东西应该测试
另一个常见的挫折对于开发者或者设计者来说测试“那些东西应该测试哪些东西不应该测试”。当没有很困难快速的规则这里应用与任何地方，有一些通用的指导方针我可以提供在做决定的时候。
-
如果代码在问题中是内建的Python函数或库，不需要测试。例如datetime库
-
如果代码是内建在Django中，不需要测试，例如Model中的字段（field）或者测试如果再见template.Node渲染，包括标签。
-
如果你的模型由自定义的方法，你应该测试，通常是单元测试
-
自定义的视图，表单，模版标签，上下文处理器，中间件，管理命令等，如果你实现业务逻辑，你因该测试代码的各方面。
令一个上游的问题时“how far down do you go",还是一样，没有正确的答案。保存为”哪里我最舒服“，如果你开始含糊”sdfldsfjs"在你呼吸 大师傅大师傅。