7,765
社区成员
发帖
与我相关
我的任务
分享浅谈测试---单元测试(散分,标题要长长长长长长长长长长长长长长)
...全文
请发表友善的回复…
发表回复
lcwl00 2011-06-13
- 打赏
- 举报
果断收藏！
ohkuy 2011-06-13
- 打赏
- 举报
[Quote=引用 10 楼 caozhy 的回复:]
……
sp1234说的精彩！
此贴应该给推荐。(
[/Quote]
大哥，你不就是版主么，给个推荐啊
好帖子！
果断收藏！
……
sp1234说的精彩！
此贴应该给推荐。(
[/Quote]
大哥，你不就是版主么，给个推荐啊
好帖子！
果断收藏！
郗晓勇 2011-06-12
- 打赏
- 举报
郗晓勇 2011-06-11
- 打赏
- 举报
这个帖子必须推荐啊~
jiambet 2011-06-11
- 打赏
- 举报
围观学习
郗晓勇 2011-06-11
- 打赏
- 举报
又移到非技术版块了?
郗晓勇 2011-06-11
- 打赏
- 举报
这是传说中的抛砖引玉么
sanyexian 2011-06-11
- 打赏
- 举报
学习了，这个帖子应该推荐啊~期待大家的畅所欲言啊~
我是一道光_ 2011-06-11
- 打赏
- 举报
嗯，来围观学习，楼主应该加分喽。
ycproc 2011-06-11
- 打赏
- 举报
学习了 看看
renyiqiu 2011-06-11
- 打赏
- 举报
我还要不断地学习才行了
机器人 2011-06-11
- 打赏
- 举报
TDD是个技术活。在需求阶段，就应该开始搭建测试框架，编写测试代码。
而且要写一些Mock，接口设计+AOP都是密不可分的
你可不想当Mock接入实际代码时，还要修改大量的测试代码吧。
另外，TDD的概念中除了重构还要在迭代中确保质量。
测试一次跑绿了是不是丢在那不管了？
当然不是，需要每次迭代都进行回归测试以确保新的迭代中没有出现Degrade。
自动化测试也是相当重要，所以设计的测试框架还应该是可配置，可扩展的。
而且要写一些Mock，接口设计+AOP都是密不可分的
你可不想当Mock接入实际代码时，还要修改大量的测试代码吧。
另外，TDD的概念中除了重构还要在迭代中确保质量。
测试一次跑绿了是不是丢在那不管了？
当然不是，需要每次迭代都进行回归测试以确保新的迭代中没有出现Degrade。
自动化测试也是相当重要，所以设计的测试框架还应该是可配置，可扩展的。
以专业开发人员为伍 2011-06-10
- 打赏
- 举报
完成业务也就是半天或者一天的时间 --> 完成任务也就是半天或者一天的时间
换句话说，既然不靠文档靠沟通，那么只有大家都心里确实同意任务已经被定为半天一天的工作量，知道怎么做，才应该开始一个任务。否则如果稀里糊涂地把界面、功能简单分解一下就开发，就是产品或者项目管理人员的失职。所以理论上要有一个团队估算每一个任务开发时间的会议，在这个会议上可以前后打乱次序讨论任务、甚至把一些任务拖到下一个迭代期，或者重新设计任务定义，或者合并到其它任务里顺带完成。
既然TDD测试是设计而不是简单的开发，那么进行TDD测试开发就依赖于分析设计。TDD测试开发一般来说不需要去跟着开发人员屁股后边去看他们写下的代码，而是应该强调：没有写好TDD测试之前是不允许开始写实现代码的。开发人员往往要知道了产品人员会怎么测试来判断业绩，而且也可以在开发中注意到许多原先理解需求是没有想到的问题。
换句话说，既然不靠文档靠沟通，那么只有大家都心里确实同意任务已经被定为半天一天的工作量，知道怎么做，才应该开始一个任务。否则如果稀里糊涂地把界面、功能简单分解一下就开发，就是产品或者项目管理人员的失职。所以理论上要有一个团队估算每一个任务开发时间的会议，在这个会议上可以前后打乱次序讨论任务、甚至把一些任务拖到下一个迭代期，或者重新设计任务定义，或者合并到其它任务里顺带完成。
既然TDD测试是设计而不是简单的开发，那么进行TDD测试开发就依赖于分析设计。TDD测试开发一般来说不需要去跟着开发人员屁股后边去看他们写下的代码，而是应该强调：没有写好TDD测试之前是不允许开始写实现代码的。开发人员往往要知道了产品人员会怎么测试来判断业绩，而且也可以在开发中注意到许多原先理解需求是没有想到的问题。
以专业开发人员为伍 2011-06-10
- 打赏
- 举报
哦，敏捷开发的每个迭代周期通常是2～6周，然后就发布产品的试用版本。它不做长期计划。不论是长期计划，还是迭代期内的计划，用一页纸就能说明白了，不需要写很多文档。敏捷开发强调沟通。每一个任务如果需要留下文档，那么找一个论坛在上面讨论一下这也就是留下文档了。不需要写特别正式的格式化的文档。特别是：不要强调格式。
完成业务也就是半天或者一天的时间，这个任务完成了，那么一切文档就可以撕掉了，不再看了（除非新来的人需要看）。只有TDD测试代码还被每个人、每隔十几分钟就使用一遍。测试只是编程，没有这些实践做基础，就可能不知道该写什么测试，把测试写成了传统的单元测试，而不是用来驱动开发的测试。
完成业务也就是半天或者一天的时间，这个任务完成了，那么一切文档就可以撕掉了，不再看了（除非新来的人需要看）。只有TDD测试代码还被每个人、每隔十几分钟就使用一遍。测试只是编程，没有这些实践做基础，就可能不知道该写什么测试，把测试写成了传统的单元测试，而不是用来驱动开发的测试。
风骑士之怒 2011-06-10
- 打赏
- 举报
学习来的。。。。
以专业开发人员为伍 2011-06-10
- 打赏
- 举报
实际上我在4.中说明的观点非常重要，即说明了TDD测试的粒度来自于前期什么样的任务说明会和讨论，同时也说明该TDD测试是什么测试而不是什么测试（不是传统的单元测试）。
郗晓勇 2011-06-10
- 打赏
- 举报
难道大牛都不屑加菜鸟为好友么
threenewbee 2011-06-10
- 打赏
- 举报
[Quote=引用 6 楼 sp1234 的回复:]
引用 4 楼 beijiguangyong 的回复:
(1)不知道哇
(2)我们现在的做法是将测试与代码分开管理,每个代码程序集对应一个测试代码程序集,而且名称对应.
(3)这个真不清楚哇
(4)就我们目前的单元测试而言就是针对于方法的.
(5)我们现在的做法是将界面测试和最后的集成测试结合,实在是想不出有什么更好的办法,希望高手们指教啊
(6)是指内部输入的问题么?我现在的做法是……
[/Quote]
sp1234说的精彩！
此贴应该给推荐。
引用 4 楼 beijiguangyong 的回复:
(1)不知道哇
(2)我们现在的做法是将测试与代码分开管理,每个代码程序集对应一个测试代码程序集,而且名称对应.
(3)这个真不清楚哇
(4)就我们目前的单元测试而言就是针对于方法的.
(5)我们现在的做法是将界面测试和最后的集成测试结合,实在是想不出有什么更好的办法,希望高手们指教啊
(6)是指内部输入的问题么?我现在的做法是……
[/Quote]
sp1234说的精彩！
此贴应该给推荐。
以专业开发人员为伍 2011-06-10
- 打赏
- 举报
有了TDD测试，才敢去强调迭代和重构 --> 有了TDD测试，才敢把迭代和重构强调成今天这种高度
郗晓勇 2011-06-10
- 打赏
- 举报
膜拜~学!习!啦!
[Quote=引用 6 楼 sp1234 的回复:]
引用 4 楼 beijiguangyong 的回复:
(1)不知道哇
(2)我们现在的做法是将测试与代码分开管理,每个代码程序集对应一个测试代码程序集,而且名称对应.
(3)这个真不清楚哇
(4)就我们目前的单元测试而言就是针对于方法的.
(5)我们现在的做法是将界面测试和最后的集成测试结合,实在是想不出有什么更好的办法,希望高手们指教啊
(6)是指内部输入的问题么?我现在的做法……
[/Quote]
[Quote=引用 6 楼 sp1234 的回复:]
引用 4 楼 beijiguangyong 的回复:
(1)不知道哇
(2)我们现在的做法是将测试与代码分开管理,每个代码程序集对应一个测试代码程序集,而且名称对应.
(3)这个真不清楚哇
(4)就我们目前的单元测试而言就是针对于方法的.
(5)我们现在的做法是将界面测试和最后的集成测试结合,实在是想不出有什么更好的办法,希望高手们指教啊
(6)是指内部输入的问题么?我现在的做法……
[/Quote]
加载更多回复（7）
