在各种敏捷开发实践中,测试驱动开发(TDD)一直处在最核心的位置。
TDD的核心在于严格规定开发节奏,一次把需求理清,一次做对、消除返工,不用调试就能获得反馈。
这是一个找虐的过程,他让你在走每一步前都必须先想好要达到什么效果,每一步都有充分的测试覆盖。
里边有三个关键:
第一步任务分解:测试先行,分离关注点,并用单元测试表达;
第二步单元测试:遵循 Given-When-Then 三段式,符合极限编程原则;
第三步小步快走:此处的坑在于很多人容易一下写多,破坏TDD节奏。
但一旦会用,节省出的时间会远大于编写测试代码而产生的工作量总和。
你有没有想过为什么明明都知道有用,但我们就是不爱写单元测试?
很多人说需求急、没时间,就算想测试也找不到接缝。为啥呢?因为你写代码的时候压根就没想一会儿怎么测啊大哥。
那怎么办,后面交付压力还跟着呢。要不就先这样吧,先放着,等过两天有空了我再补。
基本功不过关不能全赖程序员,但凭本能开发+单元测试不到位,两个加起来就是天坑。