标签分类
当前位置:首页 > > Python web开发电子书网盘下载
Python测试驱动开发 Python测试驱动开发
码小辫

码小辫 提供上传

资源
17
粉丝
17
喜欢
196
评论
2

    Python测试驱动开发 PDF 超清原书第2版

    Python web开发电子书
    • 发布时间:

    给大家带来的一篇关于Python web开发相关的电子书资源,介绍了关于Python测试驱动开发、Web编程、Django方面的内容,本书是由人民邮电出版社出版,格式为PDF,资源大小12.4 MB,哈利·帕西瓦尔编写,目前豆瓣、亚马逊、当当、京东等电子书综合评分为:8.4

  • Python测试驱动开发 PDF 下载
  • 下载地址:https://pan.baidu.com/s/1Kl9Avh6cyY0pt4QU8fmjm
  • 分享码:qv47
  • Python测试驱动开发

    Python测试驱动开发电子书封面

    读者评价

    最近学习了一本书《Python Web开发:测试驱动方法》,贯穿全书的便是测试驱动开发的编程思想。有点儿兵马未动,粮草先行的兵家思想。先简单总结一下这本书带给我的收获:1.学习了测试驱动开发的一种编程思想,与传统的瀑布开发流程又很大的出入。2.学习了如何写好功能测试,如何写好单元测试。3.先通过测试,再谈重构。

    内容介绍

    本书从基础的知识开始,讲解Web开发的整个流程,展示如何使用Python做测试驱动开发。本书由三个部分组成。第一部分介绍了测试驱动开发和Django的基础知识,并在每个阶段进行严格的单元测试。第二部分讨论了Web开发要素,探讨了Web开发过程中不可避免的问题,以及如何通过测试解决这些问题。第三部分探讨了一些话题,如模拟技术、集成第三方认证系统、Ajax、测试固件以及持续集成等。
    第2版全部使用Python 3,并针对新版Django全面升级,介绍了由外而内的测试驱动开发流程。
    本书适合Web开发人员阅读。

    内容节选

    何为测试驱动开发

    维基百科中队测试驱动开发又一个比较正式的介绍:测试驱动开发(英语:Test-driven development,缩写为TDD)是一种软件开发过程中的应用方法,由极限编程中倡导,以其倡导先写测试程序,然后编码实现其功能得名。测试驱动开发始于20世纪90年代。测试驱动开发的目的是取得快速反馈并使用“illustrate the main line”方法来构建程序。

    测试驱动开发是戴两顶帽子思考的开发方式:先戴上实现功能的帽子,在测试的辅助下,快速实现其功能;再戴上重构的帽子,在测试的保护下,通过去除冗余的代码,提高代码质量。测试驱动着整个开发过程:首先,驱动代码的设计和功能的实现;其后,驱动代码的再设计和重构。

    按照我个人的理解:将业务需求转化为功能测试及单元测试,业务代码则为了通过测试而不断的迭代。

    测试驱动开发利弊权衡(由于未实战过tdd,看法可能略显稚嫩)

    • 通过测试驱动开发,能保证业务代码能满足需求,不断的重构,能保证系统功能的正常运行。但是对于代码质量的把控,貌似很难做到。
    • 测试驱动开发思想其实并不难理解,流程无非也是在测试开发重构过程中不断流转,但是个人感觉在工程实践上其实难度挺大
    • 就个人工作经验来看,目前多数企业对于项目代码质量把控很差,项目周期紧,领导总是抱着先上线,遇到bug再解决,故TDD的开发模式在很多公司,尤其是创业公司中很难推广开,由于前期测试覆盖度不够,开发急促,导致后期上线维护异常困难
    • TDD的开发模式也应该分业务场景而看,但具体是哪些场景合适目前没有资格谈

    TDD这种方式,还是得实践。然而以目前公司的平台,基本属于不可能。不过,就算不能在公司实践TDD的开发模式,它其中最重要的核心部分–测试,会让我在今后的开发过程中更加重视这部分。

    import unittest 
    from main import Sample 
    class SampleTest(unittest.TestCase): 
      
      def setUp(self): 
        print "create a new Sample"
        self._sample = Sample("b64e5843ca7db8199c405be565fa7f57") 
      def tearDown(self): 
        print "Destory the sample"
        self._sample = None
      
      def test_GetVirusNameFromVT(self): 
        "this md5 has the VT info"
        aSample = Sample("b64e5843ca7db8199c405be565fa7f57") 
        dict_virusName = aSample._GetVirusNameFromVT() 
        self.assertTrue(dict_virusName!=None) 
      def test_GetVirusNameFromVT2(self): 
        "this md5 has not the VT info"
        aSample = Sample("2b666ffe98e465523e514d2b93b7666a") 
        dict_virusName = aSample._GetVirusNameFromVT () 
        self.assertTrue(len(dict_virusName) == 0) 
      
      
    if __name__=="__main__": 
      #unittest.main() 
      suite = unittest.TestLoader().loadTestsFromTestCase(SampleTest) 
      unittest.TextTestRunner(verbosity=2).run(suite) 

    目录

    • 前言 xv
    • 准备工作和应具备的知识 xxi
    • 配套视频 xxviii
    • 致谢 xxix
    • 第 一部分 TDD和Django基础
    • 第 1章 使用功能测试协助安装Django 2
    • 1.1 遵从测试山羊的教诲,没有测试什么也别做 2
    • 1.2 让Django运行起来 4
    • 1.3 创建Git仓库 6
    • 第 2 章 使用unittest模块扩展功能测试 10
    • 2.1 使用功能测试驱动开发一个最简可用的应用 10
    • 2.2 Python标准库中的unittest模块 12
    • 2.3 提交 14
    • 第3章 使用单元测试测试简单的首页 16
    • 3.1 第 一个Django应用,第 一个单元测试 16
    • 3.2 单元测试及其与功能测试的区别 17
    • 3.3 Django中的单元测试 18
    • 3.4 Django中的MVC、URL和视图函数 19
    • 3.5 终于可以编写一些应用代码了 20
    • 3.6 urls.py 22
    • 3.7 为视图编写单元测试 23
    • 第4章 测试(及重构)的目的 28
    • 4.1 编程就像从井里打水 28
    • 4.2 使用Selenium测试用户交互 30
    • 4.3 遵守“不测试常量”规则,使用模板解决这个问题 32
    • 4.3.1 使用模板重构 33
    • 4.3.2 Django测试客户端 35
    • 4.4 关于重构 37
    • 4.5 接着修改首页 38
    • 4.6 总结:TDD流程 39
    • 第5章 保存用户输入:测试数据库 42
    • 5.1 编写表单,发送POST请求 42
    • 5.2 在服务器中处理POST请求 45
    • 5.3 把Python变量传入模板中渲染 46
    • 5.4 事不过三,三则重构 50
    • 5.5 Django ORM和第 一个模型 51
    • 5.5.1 第 一个数据库迁移 53
    • 5.5.2 测试向前走得挺远 53
    • 5.5.3 添加新字段就要创建新迁移 54
    • 5.6 把POST请求中的数据存入数据库 55
    • 5.7 处理完POST请求后重定向 57
    • 5.8 在模板中渲染待办事项 59
    • 5.9 使用迁移创建生产数据库 61
    • 5.10 回顾 64
    • 第6章 改进功能测试:确保隔离,去掉含糊的休眠 66
    • 6.1 确保功能测试之间相互隔离 66
    • 6.2 升级Selenium和Geckodriver 70
    • 6.3 隐式等待、显式等待和含糊的time.sleep 70
    • 第7章 步步为营 75
    • 7.1 必要时做少量的设计 75
    • 7.1.1 不要预先做大量设计 75
    • 7.1.2 YAGNI 76
    • 7.1.3 REST(式) 76
    • 7.2 使用TDD实现新设计 77
    • 7.3 确保出现回归测试 78
    • 7.4 逐步迭代,实现新设计 80
    • 7.5 自成一体的第 一步:新的URL 81
    • 7.5.1 一个新URL 82
    • 7.5.2 一个新视图函数 82
    • 7.6 变绿了吗?该重构了 84
    • 7.7 再迈一小步:一个新模板,用于查看清单 84
    • 7.8 第三小步:用于添加待办事项的URL 86
    • 7.8.1 用来测试新建清单的测试类 87
    • 7.8.2 用于新建清单的URL和视图 88
    • 7.8.3 删除当前多余的代码和测试 89
    • 7.8.4 出现回归!让表单指向刚添加的新URL 89
    • 7.9 下定决心,调整模型 90
    • 7.9.1 外键关系 92
    • 7.9.2 根据新模型定义调整其他代码 93
    • 7.10 每个列表都应该有自己的URL 95
    • 7.10.1 捕获URL中的参数 96
    • 7.10.2 按照新设计调整new_list视图 97
    • 7.11 功能测试又检测到回归 98
    • 7.12 还需要一个视图,把待办事项加入现有清单 99
    • 7.12.1 小心霸道的正则表达式 99
    • 7.12.2 最后一个新URL 100
    • 7.12.3 最后一个新视图 101
    • 7.12.4 直接测试响应上下文对象 102
    • 7.13 使用URL引入做最后一次重构 103
    • 第二部分 Web 开发要素
    • 第8章 美化网站:布局、样式及其测试方法 108
    • 8.1 如何在功能测试中测试布局和样式 108
    • 8.2 使用CSS框架美化网站 111
    • 8.3 Django模板继承 112
    • 8.4 集成Bootstrap 114
    • 8.5 Django中的静态文件 115
    • 8.6 使用Bootstrap中的组件改进网站外观 117
    • 8.6.1 超大文本块 118
    • 8.6.2 大型输入框 118
    • 8.6.3 样式化表格 118
    • 8.7 使用自己编写的CSS 118
    • 8.8 补遗:collectstatic命令和其他静态目录 120
    • 8.9 没谈到的话题 122
    • 第9章 使用过渡网站测试部署 123
    • 9.1 TDD以及部署的危险区域 124
    • 9.2 一如既往,先写测试 125
    • 9.3 注册域名 127
    • 9.4 手动配置托管网站的服务器 127
    • 9.4.1 选择在哪里托管网站 127
    • 9.4.2 搭建服务器 128
    • 9.4.3 用户账户、SSH和权限 128
    • 9.4.4 安装Nginx 128
    • 9.4.5 安装Python 3.6 129
    • 9.4.6 解析过渡环境和线上环境所用的域名 130
    • 9.4.7 使用功能测试确认域名可用而且Nginx正在运行 130
    • 9.5 手动部署代码 130
    • 9.5.1 调整数据库的位置 131
    • 9.5.2 手动创建虚拟环境,使用requirements.txt 133
    • 9.5.3 简单配置Nginx 134
    • 9.5.4 使用迁移创建数据库 136
    • 9.6 手动部署大功告成 137
    • 第 10章 为部署到生产环境做好准备 139
    • 10.1 换用Gunicorn 139
    • 10.2 让Nginx伺服静态文件 140
    • 10.3 换用Unix套接字 141
    • 10.4 把DEBUG设为False,设置ALLOWED_HOSTS 142
    • 10.5 使用Systemd确保引导时启动Gunicorn 143
    • 10.6 考虑自动化 144
    • 10.7 保存进度 147
    • 第 11章 使用Fabric自动部署 148
    • 11.1 分析一个Fabric部署脚本 149
    • 11.1.1 分析一个Fabric部署脚本 149
    • 11.1.2 使用Git拉取源码 150
    • 11.1.3 更新settings.py 151
    • 11.1.4 更新虚拟环境 151
    • 11.1.5 需要时迁移数据库 152
    • 11.2 试用部署脚本 152
    • 11.2.1 部署到线上服务器 154
    • 11.2.2 使用sed配置Nginx和Gunicorn 155
    • 11.3 使用Git标签标注发布状态 157
    • 11.4 延伸阅读 157
    • 第 12章 输入验证和测试的组织方式 159
    • 12.1 针对验证的功能测试:避免提交空待办事项 159
    • 12.1.1 跳过测试 160
    • 12.1.2 把功能测试分拆到多个文件中 161
    • 12.1.3 运行单个测试文件 163
    • 12.2 功能测试新工具:通用显式等待辅助方法 164
    • 12.3 补完功能测试 167
    • 12.4 重构单元测试,分拆成多个文件 168
    • 第 13章 数据库层验证 171
    • 13.1 模型层验证 172
    • 13.1.1 self.assertRaises上下文管理器 172
    • 13.1.2 Django怪异的表现:保存时不验证数据 173
    • 13.2 在视图中显示模型验证错误 173
    • 13.3 Django模式:在渲染表单的视图中处理POST请求 177
    • 13.3.1 重构:把new_item实现的功能移到view_list中 178
    • 13.3.2 在view_list视图中执行模型验证 180
    • 13.4 重构:去除硬编码的URL 182
    • 13.4.1 模板标签{% url %} 182
    • 13.4.2 重定向时使用get_absolute_url 183
    • 第 14章 简单的表单 186
    • 14.1 把验证逻辑移到表单中 186
    • 14.1.1 使用单元测试探索表单API 187
    • 14.1.2 换用Django中的ModelForm类 188
    • 14.1.3 测试和定制表单验证 189
    • 14.2 在视图中使用这个表单 191
    • 14.2.1 在处理GET请求的视图中使用这个表单 191
    • 14.2.2 大量查找和替换 192
    • 14.3 在处理POST请求的视图中使用这个表单 194
    • 14.3.1 修改new_list视图的单元测试 195
    • 14.3.2 在视图中使用这个表单 196
    • 14.3.3 使用这个表单在模板中显示错误消息 196
    • 14.4 在其他视图中使用这个表单 197
    • 14.4.1 定义辅助方法,简化测试 197
    • 14.4.2 意想不到的好处:HTML5自带的客户端验证 199
    • 14.5 值得鼓励 201
    • 14.6 这难道不是浪费时间吗 201
    • 14.7 使用表单自带的save方法 202
    • 第 15章 高级表单 205
    • 15.1 针对重复待办事项的功能测试 205
    • 15.1.1 在模型层禁止重复 206
    • 15.1.2 题外话:查询集合排序和字符串表示形式 208
    • 15.1.3 重写旧模型测试 210
    • 15.1.4 保存时确实会显示完整性错误 211
    • 15.2 在视图层试验待办事项重复验证 212
    • 15.3 处理唯一性验证的复杂表单 213
    • 15.4 在清单视图中使用ExistingListItemForm 215
    • 15.5 小结:目前所学的Django测试知识 217
    • 第 16章 试探JavaScript 219
    • 16.1 从功能测试开始 219
    • 16.2 安装一个基本的JavaScript测试运行程序 221
    • 16.3 使用jQuery和固件元素 223
    • 16.4 为想要实现的功能编写JavaScript单元测试 225
    • 16.5 固件、执行顺序和全局状态:JavaScript测试的重大挑战 227
    • 16.5.1 使用console.log打印调试信息 227
    • 16.5.2 使用初始化函数精确控制执行时 229
    • 16.6 经验做法:onload样板代码和命名空间 230
    • 16.7 JavaScript测试在TDD循环中的位置 232
    • 16.8 一些缺憾 232
    • 第 17章 部署新代码 234
    • 17.1 部署到过渡服务器 234
    • 17.2 部署到线上服务器 235
    • 17.3 如果看到数据库错误该怎么办 235
    • 17.4 总结:为这次新发布打上Git标签 235
    • 第三部分 高级话题
    • 第 18章 用户身份验证、探究及去掉探究代码 238
    • 18.1 无密码验证 238
    • 18.2 探索性编程(又名“探究”) 239
    • 18.2.1 为此次探究新建一个分支 239
    • 18.2.2 前端登录UI 240
    • 18.2.3 从Django中发出邮件 240
    • 18.2.4 使用环境变量,避免源码中出现机密信息 242
    • 18.2.5 在数据库中存储令牌 243
    • 18.2.6 自定义身份验证模型 243
    • 18.2.7 结束自定义Django身份验证功能 224
    • 18.3 去掉探究代码 248
    • 18.4 一个极简的自定义用户模型 251
    • 18.5 令牌模型:把电子邮件地址与唯一的ID关联起来 254
    • 第 19章 使用驭件测试外部依赖或减少重复 257
    • 19.1 开始之前布好基本管道 257
    • 19.2 自己动手模拟(打猴子补丁) 258
    • 19.3 Python的模拟库 261
    • 19.3.1 使用unittest.patch 261
    • 19.3.2 让测试向前迈一小步 263
    • 19.3.3 测试Django消息框架 263
    • 19.3.4 在HTML中添加消息 265
    • 19.3.5 构建登录URL 266
    • 19.3.6 确认给用户发送了带有令牌的链接 267
    • 19.4 去除自定义的身份验证后端中的探究代码 269
    • 19.4.1 一个if语句需要一个测试 269
    • 19.4.2 get_user方法 272
    • 19.4.3 在登录视图中使用自定义的验证后端 273
    • 19.5 使用驭件的另一个原因:减少重复 274
    • 19.5.1 使用驭件的返回值 277
    • 19.5.2 在类一级上打补丁 278
    • 19.6 关键时刻:功能测试能通过吗 279
    • 19.7 理论上正常,那么实际呢 281
    • 19.8 完善功能测试,测试退出功能 283
    • 第 20章 测试固件和一个显式等待装饰器 285
    • 20.1 事先创建好会话,跳过登录过程 285
    • 20.2 显式等待辅助方法最终版:wait装饰器 290
    • 第 21章 服务器端调试技术 293
    • 21.1 实践是检验真理的唯一标准:在过渡服务器中捕获最后的问题 293
    • 21.2 在服务器上通过环境变量设定机密信息 295
    • 21.3 调整功能测试,以便通过POP3测试真实的电子邮件 296
    • 21.4 在过渡服务器中管理测试数据库 299
    • 21.4.1 创建会话的Django管理命令 300
    • 21.4.2 让功能测试在服务器上运行管理命令 301
    • 21.4.3 直接在Python代码中使用Fabric 302
    • 21.4.4 回顾:在本地服务器和过渡服务器中创建会话的方式 303
    • 21.5 集成日志相关的代码 304
    • 21.6 小结 305
    • 第 22章 完成“My Lists”页面:由外而内的TDD 306
    • 22.1 对立技术:“由内而外” 306
    • 22.2 为什么选择使用“由外而内” 307
    • 22.3 “My Lists”页面的功能测试 307
    • 22.4 外层:表现层和模板 309
    • 22.5 下移一层到视图函数(控制器) 309
    • 22.6 使用由外而内技术,再让一个测试通过 310
    • 22.6.1 快速重组模板的继承层级 311
    • 22.6.2 使用模板设计API 311
    • 22.6.3 移到下一层:视图向模板中传入什么 313
    • 22.7 视图层的下一个需求:新建清单时应该记录属主 313
    • 22.8 下移到模型层 315
    • 第 23章 测试隔离和“倾听测试的心声” 319
    • 23.1 重温抉择时刻:视图层依赖于尚未编写的模型代码 319
    • 23.2 首先尝试使用驭件实现隔离 320
    • 23.3 倾听测试的心声:丑陋的测试表明需要重构 323
    • 23.4 以完全隔离的方式重写视图测试 323
    • 23.4.1 为了新测试的健全性,保留之前的整合测试组件 324
    • 23.4.2 完全隔离的新测试组件 324
    • 23.4.3 站在协作者的角度思考问题 324
    • 23.5 下移到表单层 329
    • 23.6 下移到模型层 332
    • 23.7 关键时刻,以及使用模拟技术的风险 335
    • 23.8 把层与层之间的交互当作“合约” 336
    • 23.8.1 找出隐形合约 337
    • 23.8.2 修正由于疏忽导致的问题 338
    • 23.9 还缺一个测试 339
    • 23.10 清理:保留哪些整合测试 340
    • 23.10.1 删除表单层多余的代码 340
    • 23.10.2 删除以前实现的视图 341
    • 23.10.3 删除视图层多余的代码 342
    • 23.11 总结:什么时候编写隔离测试,什么时候编写整合测试 343
    • 23.11.1 以复杂度为准则 344
    • 23.11.2 两种测试都要写吗 344
    • 23.11.3 继续前行 344
    • 第 24章 持续集成 346
    • 24.1 安装Jenkins 346
    • 24.2 配置Jenkins 347
    • 24.2.1 首次解锁 348
    • 24.2.2 现在建议安装的插件 348
    • 24.2.3 配置管理员用户 348
    • 24.2.4 添加插件 350
    • 24.2.5 告诉Jenkins到哪里寻找Python 3和Xvfb 350
    • 24.2.6 设置HTTPS 351
    • 24.3 设置项目 351
    • 24.4 第 一次构建 352
    • 24.5 设置虚拟显示器,让功能测试能在无界面的环境中运行 354
    • 24.6 截图 356
    • 24.7 如有疑问,增加超时试试 359
    • 24.8 使用PhantomJS运行QUnit JavaScript测试 359
    • 24.8.1 安装node 359
    • 24.8.2 在Jenkins中添加构建步骤 361
    • 24.9 CI服务器能完成的其他操作 362
    • 第 25章 简单的社会化功能、页面模式以及练习 363
    • 25.1 有多个用户以及使用addCleanup的功能测试 363
    • 25.2 页面模式 365
    • 25.3 扩展功能测试测试第二个用户和“My Lists”页面 367
    • 25.4 留给读者的练习 368
    • 第 26章 测试运行速度的快慢和炽热的岩浆 371
    • 26.1 正题:单元测试除了运行速度超快之外还有其他优势 372
    • 26.1.1 测试运行得越快,开发速度越快 372
    • 26.1.2 神赐的心流状态 372
    • 26.1.3 经常不想运行速度慢的测试,导致代码变坏 373
    • 26.1.4 现在还行,不过随着时间推移,整合测试会变得越来越慢 373
    • 26.1.5 别只听我一个人说 373
    • 26.1.6 单元测试能驱使我们实现好的设计 373
    • 26.2 纯粹的单元测试有什么问题 373
    • 26.2.1 隔离的测试难读也难写 373
    • 26.2.2 隔离测试不会自动测试集成情况 374
    • 26.2.3 单元测试几乎不能捕获意料之外的问题 374
    • 26.2.4 使用驭件的测试可能和实现方式联系紧密 374
    • 26.2.5 这些问题都可以解决 374
    • 26.3 合题:我们到底想从测试中得到什么 374
    • 26.3.1 正确性 374
    • 26.3.2 简洁可维护的代码 375
    • 26.3.3 高效的工作流程 375
    • 26.3.4 根据所需的优势评估测试 375
    • 26.4 架构方案 375
    • 26.4.1 端口和适配器(或六边形、简洁)架构 376
    • 26.4.2 函数式核心,命令式外壳 377
    • 26.5 小结 377
    • 遵从测试山羊的教诲 379
    • 附录A PythonAnywhere 381
    • 附录B 基于类的Django 视图 385
    • 附录C 使用Ansible 配置服务器 394
    • 附录D 测试数据库迁移 398
    • 附录E 行为驱动开发 403
    • 附录F 构建一个REST API:JSON、Ajax 和JavaScript 模拟技术 416
    • 附录G Django-Rest-Framework 433
    • 附录H 速查表 443
    • 附录I 接下来做什么 447
    • 附录J 示例源码 451
    • 参考书目 453
    • 作者简介 454
    • 封面介绍 454

    上一篇:C语言开发从入门到精通  下一篇:七周七数据库

    展开 +

    收起 -

    Python web开发 相关电子书
    关于Python web开发的学习笔记
    网友NO.42018
    网友NO.42018

    什么是测试驱动开发?
    这里采用了百度百科的测试驱动开发词条的含义:
    测试驱动开发,英文全称Test-Driven Development,简称TDD,是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码,然后只编写使测试通过的功能代码,通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码,并加速开发过程。
    Kent Beck先生最早在其极限编程(XP)方法论中,向大家推荐“测试驱动”这一最佳实践,还专门撰写了《测试驱动开发》一书,详细说明如何实现。经过几年的迅猛发展,测试驱动开发已经成长为一门独立的软件开发技术,其名气甚至盖过了极限编程。
    如上图所示,测试驱动开发的过程如下:
    1.编写一个失败的单元测试用例;
    2.编写代码使得单元测试用例通过;
    3.重构
    如果必要的话,为每一个可能,重复此过程。

    网友NO.22433
    网友NO.22433

    测试驱动开发(TDD)是一个近些年被实践证明过的过程。把测试带入日常的编码过程而不是编码完成后才进行测试的过程应该是开发人员试图成为习惯的方式而不是空谈的方式。
    测试驱动开发的整个过程是很容易被掌握的,而且给我们带来很多的好处--代码质量的提高,但是也清晰和专注于你要达到的目标它是什么以及你要怎样达到目标。测试驱动开发也可以无缝地与敏捷开发一起工作,在结对编程的时候,能够充分被利用,你将在后面会看到。

    网友NO.45889
    网友NO.45889

    测试驱动开发心得体会
    手头开发项目时进行了TDD,发现它非常好用,具体表现在如下方面:
    1.引导程序员设计合理的功能粒度和易测的外部模块接口。
    2.自动化测试,能够在保证质量的前提下进行重构,对代码进行修改后可以方便地运行单元测试,以保证代码没有改成屎。

    3.测试用例可以作为api demo文档,团队内程序员问我某个工具类的API如何使用,我让他去看单元测试的API调用方法。
    4.提高开发速度,虽然测试代码是业务逻辑代码量的2-3倍,但是减少了大量基本逻辑错误,减少了返工工作量;减少调试时间,把精力放在基本功能模块及其关联的交互上,而不从全局考虑功能。

    Copyright 2018-2019 xz577.com 码农之家

    版权责任说明