写作单元稍后测试

我知道TDD风格是首先编写测试,看到它失败然后去做绿色,这是好东西.有时它真的对我有用.

然而,特别是当我尝试一些东西(即不确定设计,不确定它是否会起作用)或疯狂编写代码时,我不想编写单元测试,这会打破我的流程.

我倾向于稍后编写单元测试,特别是在事情变得过于复杂之前.还有另外一个问题,以后写它们通常更无聊.

我不太确定这是不是一个好方法(绝对不是最好的).

你怎么看？您是否编写代码以后编写单元测试？或者您如何处理此流程问题或实验设计/代码阶段.

我所学到的是没有实验代码,至少不能在生产环境和/或紧迫的期限内工作.通常进行实验,直到某些东西"起作用",此时成为生产代码.

另一方面,TDD从一开始就会带来更好的代码设计.你会更多地思考它,重新编写它,比你在事后编写测试更频繁地重构它.

事后我写了测试.从那时起就更好了.他们总是值得拥有.

但是,我不得不说,在编写测试代码之前我第一次编写它们,它非常令人满意.不再需要手动测试.我感到很惊讶它的感觉有多好.

此外,我倾向于在重构遗留代码之前编写单元测试 - 几乎按照定义,这意味着我正在编写测试来测试已编写的代码.提供安全毯,使我更容易进入其他人编写的大块代码.