1
LokiSharp 2018-04-13 09:08:35 +08:00
这里,讨论技术的人里面业余开发者比较多。。。没有规范约束的话没什么人愿意多写测试的。。。
|
2
projectzoo 2018-04-13 09:27:51 +08:00
发现楼主似乎用键盘刷网页?
|
3
asj OP @projectzoo 是的 vimium
|
4
codehz 2018-04-13 09:52:44 +08:00
TDD 还可以理解为 Type-Driven Develop (
|
5
Zeahoo 2018-04-13 10:01:48 +08:00
看完了,楼主是看啥学的 TDD,感觉用 TDD 方式写代码,心里会比较有底。
|
6
cxh116 2018-04-13 10:10:33 +08:00
没有什么欢迎不欢迎,只有个人的喜欢不喜欢.
这就跟 v2 喜欢推荐 apple 产品一样. 楼主明明说了不要 mac ,还狂推荐,有意思吗? 跟一个撸着袖子就是干,一个文件写到底的人谈 TDD ,有意思吗? |
7
asj OP @Zeahoo TDD 基本概念很简单,好像是在解析极限编程里最先看到的。要想真正用起来摸索了很久。其间收获最大的书是 重构,修改代码的艺术,clean code。
|
8
sulang 2018-04-13 10:31:08 +08:00
我司现在全部要求 TDD,很爽
|
9
asj OP |
10
chenxytw 2018-04-13 10:45:38 +08:00 6
TDD 比较适合有明确目标且目标不会轻易变更 0 0
国内的程序员工作环境,能让产品不三天两头改需求。不随意变更需求截止时间就烧高香了 0 0 在需求时间很紧,且随时可能变更需求的情况下,TDD 有些吃力不讨好 0 0 可能刚写完 T, 准备开始下手了,产品和你说这里要改,然后截止时间要压缩,这种情况下能选择抗住压力去改 T 然后按部就班的做完的人很少。 |
11
niubee1 2018-04-13 10:53:56 +08:00
匆匆写好的 T 的代码有 bug 怎么办? 谁保证你的 T 没有 bug? test test 代码的 test 代码, 那么谁又保证你的 test test 代码的 test 代码没有 bug? TTTDD ?
|
12
asj OP |
14
qile1 2018-04-13 11:09:25 +08:00 via Android
@chenxytw 我想请问下我前段时间弄了个这种代码 python3.6 的:
首先从 oracle 数据库查影像 dcm 文件路径, 然后通过本地映射驱动器,把路径转为本地路径,使用 gdcm.exe 程序运行 cmd 批处理命令把 dcm 文件转为 png 文件, 然后用 pil 把 png 转为 jpg,然后利用 py 的 ftp 库把文件上传到另一台 ftp 服务器 然后连接另一台 mssql 数据库把文件路径转为 ftp 地址写入数据库表里 这个如何写 tdd |
15
qile1 2018-04-13 11:10:29 +08:00 via Android
忘记说了,正常程序开发我在别地方,服务连接上面说的两个数据库及文件服务器,我在外网,那些服务器安装在医院内网
|
17
wspsxing 2018-04-13 12:23:23 +08:00
|
19
gladuo 2018-04-13 12:34:45 +08:00
Cool
|
20
feverzsj 2018-04-13 12:40:09 +08:00
tdd 开发效率太差,互联网公司最喜欢的是直接出产品让用户测试,大不了快速迭代
|
21
ericls 2018-04-13 12:50:53 +08:00 via iPhone
@feverzsj 大方向可以 有些地方 特别是明明清楚一定要有测试才放心的地方 不如就 TDD 咯……
|
22
Phariel 2018-04-13 13:28:08 +08:00 via Android
个人是反 TDD 党 随着 IDE 的不断增强类型检查不断深入以及语言越来越成熟 在代码层面出错的概率已经降低了很多 现在出错的大多是数据层面的东西 你数据开发的时候 mock 的再好也挡不住上线出幺蛾子 这就得快速上线→让用户来测→快速迭代来保证
|
23
hu6360567 2018-04-13 13:29:17 +08:00 via Android 4
我们开发一般都是 DDD,deadline driven
|
24
we000 2018-04-13 13:31:59 +08:00 1
我个人觉得 TDD 以及很多软件工程的方法, 本质上都是为了保证猴子编码的质量, 把人当猴子当工具, 默认都是低质量的码农.
出于个人兴趣和意愿的话, 很少有人愿意这么搞. |
26
chenxytw 2018-04-13 13:56:10 +08:00
@asj
从道理上来说你是对的,但从国内的现实来说,缺少时间的考虑。 维护一份完善的 100%覆盖率的 case 基本上等同于开发一份业务代码了。 国内一大堆赶工的东西,上线后 bug 都一大堆,我甚至都可以想到可能连基本的自测都没有做好了。 让他们去自增差不多一倍工作量去维护 case 简直是天方夜谭 0 0 而且 TDD 也不是一个人做可以不管团队其它人的东西,只要一个人没有按照 TDD 来搞,就很可能导致 TDD 执行不下去。 |
27
chenxytw 2018-04-13 14:08:49 +08:00
@qile1 额,TDD 的前提当然是你能有一个跑通 case 的环境。
假设这个环境有了,那么 case 简单点划分可以是 case 1. 正常情况 1.1 dcm 路径指向文件是否存在 1.2 png 文件是否存在 1.3 jpg 文件是否存在 1.4 另一台 ftp 文件是否存在 1.5 mssql 中 ftp 记录 case 2-n. 异常情况 如果代码中有预期处理异常情况的,相对应的 case 至于实现测试代码的方式很多, mock 呀,甚至自己单独写一份测试代码都可以 |
28
asj OP |
29
amon 2018-04-13 14:22:33 +08:00
之前有个帖子是你所在公司开发有多少人,结果都是几个人,甚至一个人的。。。
说明 v 友所在小公司居多,还没有养成习惯的。 |
30
czzhengkw 2018-04-13 14:29:41 +08:00 1
|
31
chenchangjv 2018-04-13 14:57:36 +08:00 via Android
我还以为是……时分复用,又要炮轰移动了呢
|
32
Martin9 2018-04-13 15:09:45 +08:00
键盘控制鼠标好用么,准确度啥的。。
|
34
AntiGameZ 2018-04-13 15:30:39 +08:00 1
TDD 对工具,平台的要求太高了。很多时候配个持续集成都磕磕巴巴的公司,或者上了持续集成但是部署基本还是要靠手的情况下,TDD 成了负担而不是解决方案。
程序员如果一周就开一个小时的会,沟通基本靠邮件。有完善的持续集成和可依赖的本地测试环境,写好的代码 commit 后可以不用管的话,估计 TDD/BDD 才会更受欢迎才是。 |
35
lance0z 2018-04-13 15:58:32 +08:00
现在大部分纯互联网公司比较注重快速,迭代,即敏捷开发模式。
|
37
xiaozhizhu1997 2018-04-13 16:45:00 +08:00 via iPhone
难道只有我以为楼主想说中国移动
|
39
hantsy 2018-04-13 16:58:37 +08:00
@AntiGameZ 真正的 Engineering,几乎要做到 no meeting,。。至于国内沟通还是靠吼的方式,几乎不可能。
TDD 永远不会成为负担,在项目前期,好像写测试走通一个自动化 Pipeline 很费时间,但不写测试的后果是,项目后面花几倍的人力和物力去保证质量,加班就是变成常态了。 |
40
lightening 2018-04-13 17:00:57 +08:00
有的事情适合 TDD,比如有明确需求,知道自己要做什么。有的事情不适合 TDD,比如实验性质的科研项目。关键还是要看场景。
我个人会在某些情况下使用 TDD,但不会过分神化 TDD。我并不认为 TDD 适合所有场景。 另外贴一篇反对的声音: http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html |
41
q397064399 2018-04-13 17:10:36 +08:00
反对 TDD,上个迭代写的代码,下个迭代 逻辑就改的面目全非了,别说啥 OCP 原则了,
一般都是从脑子里 找出所有需要改动的地点,然后赶紧铺代码,啥 TDD,写个测试,首先要保证测试是正确的, 如果你的 testcase 在整个模块的生命周期就执行那么几次,然后又要被改动,那 testcase 的意义又何在呢? |
42
MajorAdam 2018-04-13 17:11:39 +08:00
妈耶, 整天改需求的
|
43
asj OP |
44
asj OP @q397064399
如果你的 testcase 在整个模块的生命周期就执行那么几次,然后又要被改动,那 testcase 的意义又何在呢? --------- 不能赞同更多。 所以我巴不得改代码的时候,每敲一下键盘就跑一次 testcase。 |
45
kaneg 2018-04-13 19:59:10 +08:00 via iPhone
TDD 说起来是一种增加代码单元测试覆盖率的方式,但在实际中,很多程序员是排斥写单元测试的,所以很多搞 TDD 都是虎头蛇尾,一旦没有强势的管理层推动,往往就不了了之了
|
46
yingfengi 2018-04-13 20:37:53 +08:00 via Android
我这联通好像都是 FDD,等等,我们说的应该不是同一个东西
|
47
langjiyuan 2018-04-13 20:54:12 +08:00
需求变动太大,一通电话需求改了大半,求着发封邮件确认.
TDD 是个好东西,但是经不住 漫天飞舞的需求更改. 如果可以搞定方案,宁愿前期加班赶测试代码... |
48
kx5d62Jn1J9MjoXP 2018-04-13 21:02:36 +08:00 via Android
tdd 从来就没受过欢迎,声势很大但从来都是非主流
|
49
n1dragon 2018-04-13 21:35:22 +08:00 via iPhone
我觉得通过写 test case 能让人更明确代码的逻辑,而且能模拟一些不常见的 edge case
|
50
Philippa 2018-04-13 21:48:17 +08:00 via Android
按照经验, 测试是必须的, 但可以后面写。然而文档是最重要的, 文档驱动能很好地限制产品, 可靠地传达产品设计思路。那才是消耗最大的地方。现实中 TDD 带来的一点优点, 远远不如项目管理的重要性。我宁愿代码是避免多重继承的, 或是糟糕变量名又多重封装的, 这些比测试更重要。不然协作成本远远高出质量成本。有少量的质量问题通常也可以接受。
|
51
hxtheone 2018-04-13 22:31:42 +08:00 1
https://github.com/MrHuxu/leetcode 我也是这样来做 leetcode, 但是在工作中很难能做到这样, 讲真, 如果用写测试来当工作量汇报的话, 八成会被领导干死
|
52
dddd1919 2018-04-13 22:38:10 +08:00
一般 T 都最后补,很少 TDD
|
53
kid1412621 2018-04-13 23:03:28 +08:00
@codehz 我还是以为 tdd fdd
|
54
msg7086 2018-04-13 23:21:02 +08:00 1
我来加个反对意见吧。
我个人是很不喜欢 TDD 的。增加测试覆盖很好,但是我觉得 TDD 本末倒置了,很多时候为了测试而测试,反而忘了软件开发的原本要求 —— 软件开发。 比如要设计一个返回 输入+1 的功能,先写单元测试: assert(add_one(4), 5) assert(add_one(-1), 0) 然后写代码 add_one(in),会不会有人写成 return in == 4 ? 5 : 0 ? 还有,当你没有一个方法的时候,先写测试再写方法,会让人的思维更优先地去让方法满足测试,而不是满足项目的需求。有很大的可能,会导致面向测试开发,而不是面向需求开发。 我一直遵从的是 BDD,基于行为驱动开发,大量测试程序的行为而不是内部实现。可以剥离出来的类库函数则剥离出来以后再测试其对外的 API 接口。因为程序行为是和用户需求相关,而非内部实现,所以重构的时候不会增加大量的重写单元测试时间,同时也能保证需求里规定的行为被正确实现。 当然我们的 BDD 里,集成测试是在功能结构设计完,代码写完以后再上的。 |
55
fish47 2018-04-13 23:53:18 +08:00 1
https://github.com/fish47/leetcode
做算法题写一下验证是有用的,例如用 DFS 来验证 DP 算法。 https://github.com/fish47/MPVDanmakuLoader/tree/dev 普通工程写单元测试,好处是帮助你调整出更清晰的架构,避免代码改坏。坏处是多了一些不必要(?)的抽象 /封装。 |
56
bitlaoyuan 2018-04-14 06:51:28 +08:00
一个人做自己的项目,一直都是 BDD,Bug Driven Develop
|
57
ghostsf 2018-04-14 10:36:54 +08:00
不适合 XP 极限编程
|
58
lowzoom 2018-04-14 14:31:33 +08:00
TDD 是好东西,可惜真正理解并掌握正确设计方法的人极少
很多人都是理解个皮毛,然后就骂骂咧咧地用回他们那套“去实际运行环境中运行打断点看变量 /在控制台临时打印输出”的小学生做法了 |
59
mightofcode 2018-04-14 17:01:05 +08:00
TDD 不能应对快速变化的需求
|
60
asj OP |
61
asj OP @msg7086
> 增加测试覆盖很好,但是我觉得 TDD 本末倒置了,很多时候为了测试而测试 ----------- 同意,为了增加测试覆盖率而 TDD 就是本末倒置。 > 先写单元测试:…… 然后写代码 add_one(in),会不会有人写成 return in == 4 ? 5 : 0 ? ----------- 如果程序员觉得先写成这一步有帮助,不妨写成这样再重构。当然不能停留在这里。原因是这种代码其实是重复,实现代码与测试代码之间“知识”的重复。具体就不多展开了。 > 先写测试再写方法,有很大的可能,会导致面向测试开发,而不是面向需求开发。 ----------- 如果在没有实现代码的时候就不基于需求写测试用例,那确实会出现这种问题。 |
62
msg7086 2018-04-15 09:08:49 +08:00
@asj
TDD 提的做法是,先写测试,拿 Fail,实现他,拿 Pass,重构他。 而我们一般的做法是,先设计结构,写代码,然后写行为测试,拿 Fail 或者 Pass,然后再重构他。 这样能够让「绝对测试」和「纯结构设计」之间找到一个比较经济实惠的中间点。 事后测试的缺点是容易放过一些边界条件,因为测试会跟着代码的思维走,只能查到预期的错误,而很难查到非预期的错误。所以我们的事后测试还会和 Peer review 结合,让另一个人来检查代码和测试,从另一个视角来寻找问题点。 优点嘛,可以有更多的时间花在结构设计和功能实现上,提高开发的效率,又不会引入太多的技术债,所以比较经济实惠。 |