#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"在你呼吸 大师傅大师傅。