bjdp.org第15次编程道场回顾
* 时间:2014.05.09, 2:30-6:45pm
* 地点:北京天正华光科技开发有限公司
* 参加人数:13人
* 活动主题:用编写Stub的方法来为编程操练题目TirePressureMonitoringSystem的C#已有代码添加单元测试
* 伍斌完成该题目的源代码:请点击本微信左下角“阅读原文”链接
* TirePressureMonitoringSystem题目描述:
在这个轮胎气压监测系统中,有两个类Alarm和Sensor,其中Sensor类负责获取用随机数来模拟生成的轮胎气压值,而Alarm类则检查Sensor传来的气压值,若在正常范围之外则报警。操练要求为Alarm类编写单元测试。
活动过程
1. 各位匠友自我介绍与问题收集
2. 伍斌现场编程演示用编写Stub的方法来为TirePressureMonitoringSystem添加单元测试
2. 各位匠友结对用编写Stub的方法来为TirePressureMonitoringSystem添加单元测试(每对7分钟)
4. 回顾与问题解答
回顾要点
Well
* 题目有趣
* 自己动手印象深刻,思想境界再次提升
* 结对编程操练环节很好,注重了实践
* 结对编程有利于团队共同进步
* “演示+实践”模式效果很好,可以发现团队存在的问题,并帮助纠正
* 懂得了在结对编程时要说出自己的思路让同事明了
* 懂得了测试的方法可以用中文命名以便于产品专家和测试人员阅读
* 了解到一些新知识,学习了不同思维的写单元测试的方法
* 了解了测试的重要性
* 学习了TDD
* 认识到了结对编程的好处
* 认识到了烂代码是如何写出来的
* 明白了怎么去测试一个方法单元,从什么角度入手
* 普及TDD相关知识
* 在测试的保护下提示了需求变更的自信
* 让大家在压力下编程,考验个人水平
* 见识了good code怎样去写
Less Well
* 主持人用于讲解的时间有些短
* 结对编程操练时间有些短
* 主持人可以准备一些参考资料供匠友操练参考
* 讨论的话题范围能否更广?比如如何建立TDD团队
* 希望能讲一些有关前端开发的东西
Puzzles(含我个人的解答)
1) 平时工作中TDD做得不好,Test写得少,不知如何写单元测试,该怎么办?
答:我觉得解决这个问题最好的办法是自己用大量时间刻意地操练TDD。我个人把Kent Beck的那本Test-Driven Development by Example一书的第一部分The Money Example那80页的TDD过程,一个字符一个字符地在IDE里敲进去并运行测试,仔细观察代码的变化,获益匪浅。该书中译本购买链接:http://m.china-pub.com/touch/touchproduct.aspx?id=3768516。对代码有兴趣的匠友可以参考我敲的上述代码:https://github.com/wubin28/money-example-by-kent-beck-java
2) TDD的门槛是否较高?TDD的效率有多高?如何能轻松做TDD?
答:TDD的门槛是比较高,因为要掌握TDD,需要长期刻意地操练。Martin Fowler去年在中关村演讲中谈到,一个团队需要花2年左右的时间才能达到TDD运用自如的水平。
TDD的效率来自以下几方面:1)专注,因为TDD专注于测试所描述的特性,能有效防止镀金;2)重用,TDD中编写的测试能自动化地反复重用来运行,比事后发现bug时再手工debug这个不可重用的过程要效率高很多;3)反馈快,大量的bug在程序员手里得到解决,省却了大量测试工程师测试、报告bug和程序员重现、修复bug的时间。
要轻松地做TDD,需要程序员用大量时间来刻意地操练。
3) TDD如何能快速适应变化?
答:TDD的代码都是有测试的,而易于测试的代码由于其高內聚低耦合的特性,同时也是易于扩展的,而易于扩展的代码在测试的保护下就能快速适应变化。
4) TDD如何与地理信息系统GIS相结合?
答:我不懂GIS的开发。但如果GIS系统里面也有类似于MVC的结构,那么TDD就可以在model和Controller层面进行应用。
5) 在工作中曾经把每个方法都写了单元测试,但后来就不写了。如何避免这种情况?
答:不是每个方法都值得写单元测试的。值得写单元测试的方法是那些暴露到外界的公共接口的方法。另外测试要面向变化较小的业务领域和代码外在行为,而不要面向那些容易变化的代码内部实现细节。
6) 如何把代码测试好?
答:需要多读书,多读高手的代码,多操练。
7) Stub与Mock的区别?
答:简而言之,Stub是带有假数据的“替身”,而Mock除了是带有假数据的“替身”之外,同时其内部还提供一些Verify()方法来验证另外一些必须被调用的方法已经被不多不少地调用过了。
8) TDD适合怎样的场景?是否适合所有的业务测试?
答:TDD适合系统的中间层的开发。但至今在表现层方面,尚未找到用测试来驱动开发用户界面的方法。在与数据库相关的持久化层方面,有些专家正在探索用TDD来驱动开发数据库应用,并取得了一些成果,感兴趣的匠友可以参考Max Guernsey III的著作Test-Driven Database Development,该书中译本《测试驱动数据库开发》最近将会上市。
9) 单元测试这样写是否对个人能力要求太高?而且会造成耗时过长?该怎么办?
答:编写单元测试的技能的确需要程序员利用大量时间来刻意地操练。一旦熟练,就能利用TDD“专注、复用和反馈快”的特点而节省时间。
10) 若测试代码比生产代码都多,那该怎么办?
答:测试代码也需要用重构的手法来消除重复。
11) 不大理解怎么能通过测试来驱动开发。具体的做法是什么?
答:可以用丰田汽车的“拉动式”精益生产来理解测试驱动开发。在丰田汽车制造系统中,上游部门的零件是否生产,是由下游组装部门的需求来“拉动”的。同样,在TDD中,生产代码是否开发,也是由测试代码的运行来“拉动”的。换句话说,那些没有被测试代码所用到的生产代码,都应该被删除。
12) TDD如何适合团队?
答:TDD像是一个被相亲的对象,是否适合团队,那真的要看缘分。先从一些对TDD感兴趣的团队成员入手吧,像微信那样口口相传地影响他人。而不要像搞运动那样地生硬推行。
13) 压力下如何让领导和团队成员重视测试?
答:测试是保证质量的有力工具。老外用“技术债务”来引起老板对代码质量的重视。但中国没有国外的信用体系,杨白劳比黄世仁厉害。所以在国内,可以用“反馈迟缓”或“失控”来引起重视,因为华人都有皇帝梦,哪个皇帝希望反馈迟缓或失控呢?
14) 如何验证需求?
答:需要开发、测试、业务人员一起来讨论需求,并使用验收测试驱动开发ATDD。
15) 如何评价烂代码?
答:一般人认为烂代码就是难理解、难测试、难扩展的代码。我认为烂代码就是“反馈迟缓”的代码:难理解是代码在理解上反馈迟缓,难测试是代码在行为验证上反馈迟缓,难扩展是代码在维护上反馈迟缓。
16) 什么是好代码?如何养成写好代码的习惯?
答:反馈快的代码就是好代码。详见Bob大叔的著作Clean Code。
17) 英文不好时如何写代码的命名?
答:千万不要用拼音,更不要用拼音的首字母缩写。可以用http://translate.google.cn/?hl=en来进行中英互译。另外推荐去公益英文演讲会toastmasters.org去操练英文的听说读写,每小时仅20元左右。
18) 如何避免明知是烂代码还是继续写的情况?
答:团队需要达成共识。需要刻意地操练。需要参加类似bjdp.org这样的编程道场活动。必要时需要熟悉TDD的软件开发咨询师来一起结对编程一段时间,养成习惯。
19) Code Kata的操练形式是怎样的?
答:可以是一个人在家单独练;也可以是一个人在投影仪上为大家演示(有备编程操练);也可以是大家轮流在投影仪上结对编程(编程道场);也可以是大家分头两两结对编程(编程静修)。详见我正在撰写的《驯服烂代码》:http://blog.csdn.net/wubinben28/article/details/17527505
20) 如何驱动项目?
答:这个需要咨询管理专家。不妨关注微信订阅号“敏捷一千零一夜”:agile1001
21) 项目中人员该如何分工?
答:同上。
22) 个人职业发展您有何建议?
答:需要熄灭“贪嗔痴”,勤修“戒定慧”。不妨在网上搜索“冬吴相对论”第166期《寻找定见》的音频mp3收听。
23) 测试团队的组建?要测试什么?
答:这个需要咨询测试专家。不妨加入软件开发咨询师吴穹博士的QQ群“分层自动化测试”:20442181.
24) 逻辑能力怎样拓展?
答:多读书、多看高手代码、多操练。
25) 举办bjdp.org编程操练的目的是什么?
答:和众位匠友一起,形成对靠谱软件开发方法的信仰,来固化所学到的靠谱的软件开发新习惯。
--------------------------------
程序员、测试工程师、产品需求专家的公益编程操练社区:bjdp.org北京设计模式学习组。微信订阅号:bjdp_org