程序员的职业素养--测试驱动开发

这是本书的第五章

测试驱动开发 TDD，先写测试的编程。

Bob举得例子说 kent能在每30秒左右运行一次程序。

（这有点象更开始学习PHP编程一样，没写一行代码都要让浏览器去执行一次看一下效果，这样确实能够减少非常多的错误，但是现在我的工作中似乎是经常要写完整段的内容才开始简单测试，还不是单元测试，因为我还不会呢。不过我确实是在抱着一份这样的心理：这次一会成功的。呵呵，这是不专业的。还有就是，我现在可以感觉到写完的代码好像会出错，这是个好现象？

对于PHP 这语言如何实行TDD我真的不清楚，我了解一点java，执行程序要先进行编译，在安装linux系统时也知道编译安装程序的痛苦。可以比较容易的理解先做好测试的好处。

但是对于PHP 感觉好像，手动的简单测试就能够完成很多内容了。

）

此事早有定论

GOTO是有害的。TDD确实可行。

TDD的三项法则

1.在编好失败单元测试之前，不要编写任何产品代码。

2.只要一个单元测试失败了，就不要在测试任何代码；无法通过编译也是一种失败的情况。

3.产品代码较好能够让当天的失败的单元测试通过测试即可，不要多些。

遵循这三条法则大概每30秒就要进行一次测试。

TDD的优势

确定性。Bob举例说FitNesse 的代码有6.4万行，其中有2.8万行是测试代码，如果要做改动，只要最后对执行者2.8万行代码就可以知道是否现在的操作是正确的。

缺陷注入率

bug非常少。

勇气

当你看到糟糕的代码时，你为什么不修改呢？因为你不知道自己是去修改还是去破坏了什么，最终他会缠上你。TDD最强大之处就是有一套值得信赖的测试。

文档

遵循三项法则，每一个测试都是一个示例。

设计

通常情况下，你对于想要写的代码十分清楚，但是三项法则却要求你先写出目前无法通过的单元测试，因为要测试的代码尚未诞生！这意味着必须测试将要编写的代码。于是，为了测试需要就要考虑解耦的办法。（这就是设计了）

专业人士的选择

TDD的局限性

如果弊大于利专业的人士就不会选择它。

感受：

这篇的插画师两个男士在一台电脑前，背景是一副画，画中是个湖。惬意而基情。因为你不知道他们俩的手在下面做什么。O(∩_∩)O哈哈~

这就是理想的结对编程吧。

确实有个人在边上一起讨论一起编写要能够快速的解决问题。而对于TDD我还没有试过。但是Bob确实在大力推销这个方法。它从你开始编程时便要求你做出合理的正确事情，从而时每一步都能够做的正确。所谓步步为营？看到糟糕的代码确实想去改动，但是真的不好改。我就有这样一段代码，不过幸好那个模块暂时不再使用所以可以先不用管它。代码糟糕并不是不能够运行是确实不够简洁，不够理想。至于理想状态是什么，我其实也还不清楚。还需要不断的去实践吧。