第五章 TDD和单元测试

首先,调试代码比写代码难一倍。

因此,从这个意义上讲,调试你穷思竭虑写出的代码时你将才尽思穷

你所正在做的...

我都做过这样的事——写一大堆代码然后艰难地使它工作起来,也就是建造再修正。测试是在代码写完之后地事情。测试总是一件加上来地事情,这就是我们过去唯一所知地方法。

这种很难预料的过程被亲切地称为“调试(debugging)。调试总是风险和不确定地来源。修改一个bug可能导致产生另一个bug,有时候是一系列其他bug。这传统的法被称为“后期调试式编程”(Debug-Later Programming,DLP)。在DLP中,代码先设计并写出,即代码“写完”之后才进行测试。有趣的是,这个“写完”的定义忽略在后期调试和测试反馈中超过一半的开发工作量。

DLP可能在项目早期可以快速推进,项目后期就不是那么有效了。随这系统的集成度越来越高和时间的推移,隐藏越深的bug会逐渐暴露出来,而且随着开发者的记忆模糊了,开发者很难发现早期在代码中引入的错误,定位的错误的代价会在项目后期越来越凸显出来。所以很容易看到瀑布模型的开发者在会在开发后期忙成一团。

What can we do ?

一些有远见的人看到了这里的潜在问题,他们发现短的开发周期产生的问题会少一些。他们发现积极的测试自动化可以节省时间和精力。测试驱动开发(Test-Driven Development,TDD)就是其中一种方式——一种有效的方式,它可以把测试贯穿到软件开发脉络中,它是你的代码的最坚实的保障。

results matching ""

    No results matching ""