tdd

README

tdd

练习tdd流程的仓库,附加ci. 因为是一个练习项目,所以不走pr

依赖注入

di,ioc的一种,用途是解耦,通常是用接口类型来代替具体类型

下面几种场景才会体会到di的威力:

• 测试代码
• 关注分离点 某某在何时做了何事 完全可以分离,测试方便,复用性也高
• 代码复用

迭代

什么叫迭代:

• 用最小的步骤,让软件可用
• 一个迭代,正好对应一个tdd循环
• tdd是xp(极限编程)的一种,xp属于敏捷的一种,迭代又术语敏捷的核心词汇
• 所以一次迭代用tdd的 红灯-绿灯-重构 来解释,刚刚好,都强调了最小步骤达成
• 写的程序在硬盘挂掉之后还能跑,这种做法和敏捷一点关系都没有

kent beck

• 是tdd和极限编程的开创者
• 所有编码的策略都应该是:
  • make it work 对应tdd的绿灯,最小满足需求的实现
  • make it right 对应tdd的重构
  • make it fast
• 过早的优化是万恶之源,优化不要在绿灯/红灯阶段做,要放在重构中

反射

• 反射,程序执行期间,检查自身结构
• 既然有反射,为啥函数调用不全部规定为intferface{}
  • 作为函数的使用者,失去了类型安全检查,编译器也无法通知,也不清楚函数具体可接受什么类型的参数
  • 作为函数的作者,每个参数都用反射去处理,代码就很笨拙了,可读性差
• 所以,除非真的需要,一般不要使用反射

关于tdd测试

• 小步快走(尽快摆脱红色警告[不管是编译错误,还是红灯],只写必要的代码)
• 最小实现,可能不是实际需要的实现,不过没关系,在重构中修复即可
• 在一个迭代中,不要做太多的尝试,不然很容易陷入复杂问题的陷阱(用tdd解决问题时,发现很迷茫,就需要思考一下是否尝试的太多)

关于集成测试:

• 集成测试更难以编写
• 失败的原因很多,更难修复,因为你不知道具体是哪个组件出了问题(模块可能有10个组件)
• 集成测试有时运行慢,可能要访问db等

road map

• 基础tdd练习
• ci