困惑 Test'(noun)'

四个月前刚刚读过TDD By Example, 这两天打算重温一下.读到25章 Test-Driven Development Patterns 有一节
叫做 Test'(noun)', 怎么读也搞不懂作者在说什么, 总的感觉kent像是在说测试本身是一个名词, 而不是动词.
作者接着用Wenberg的反馈图来说明: 当压力越大, 越频繁的运行测试, 越频繁的运行测试, 犯错误的机会越少, 压力就越少.

不明白的地方主要有:
1.wenberg的反馈图怎么就证明Test是名词而不是动词呢?作者真正想用test'(noun)'来表达什么呢?

2.还有这么一句话"Should you run the test after you write it, even though you know it's going to fail?" No, don't bother
接着作者举了一个实现in-memory的transaction的例子来说明上面这句话. 不但上面这句话本身让人搞不懂, 看了例子之后,更加迷惑.

不知道有没有人读过这本书, 真正理解作者在说什么?

1、在你想要写任何代码时，首先写测试描述你到底想做什么，然后编写代码让测试通过。
2、一个刚写出来的测试必定会失败，所以你可以不去运行它，写好测试之后便开始编写功能代码。（不过我不喜欢这样做。失败有很多种，包括环境设置失败和功能未实现。）
3、TDD是要靠做的，不是靠读书的。

gigix, 首先谢谢你的回复.
     gigix 写道:

     我理解你的意思, 但这与我的问题有多大的关系呢?

   

    一个刚写出来的测试必定会失败?我看未必.

  
   我同意你的观点.顺便说一下, 我从事TDD编程有一年了, 一直在实践, 而不是光读死书. 我想我们无论看书,或实践的时候都不应该糊里糊涂, 不理解的就是不理解, 不能欺骗自己.还有我觉得大家因该多交流自己的读书心得, 这样能避免对书的一些主观误解, 并能加深理解. 这不会与你说的"做"相矛盾吧?

很多测试根本没必要,测试也并不需要走极端,写必要的测试就可以了

那么你为什么要写它？

gigix写道:

我们使用测试的一种用途,是用来"试验"我们的一些design ideas, 以便更快的得到反馈。这时我们不确定测试是失败,还是成功, 我想让计算机来告诉我结果.

还有另一种情况, 假如你的测试写错了呢(你不会告诉我你从来没犯过错误吧?), 你假设测试本应该失败, 可是由于你的某种错误, 实际上测试会成功, 你如何来检查?很显然,让计算机运行测试会尽早的告诉我们结果.

呵呵，我想你没明白原文和gigix的意思，TDD，测试驱动开发，测试先行，也就是在你的业务源码出来之前，先写测试代码，测试代码写好了，业务代码也就出来了，不然通不过IDE的编译，所以在你刚写好测试代码时，要么没编译好，要么业务源码没有实际动作，当然不要运行的好了。

toafu写道:


你怎么知道原文和gigix的意思指的是代码还不能编译的时候?

当然, 如果测试代码不可以编译, 我当然要先让它可以编译.我在这里指的是代码可以编译,fail指的是运行时的fail 而不是 compile error.

因为你先写测试代码的时候，其中要测试业务源码的逻辑，而业务代码还没写出，当然编译不过了。

代码还不能编译通过是不要运行测试代码的可能原因之一，还有就是即使编译通过了，业务代码的逻辑可能还未完善，这在这本书开头的那个例子里面说的还是比较清楚的。

可能我的理解有所偏颇，大家可以讨论一下，谢谢。

toafu写道:


sure, 这是TDD时的基本步骤.toafu, 我想你是误解我的意思了, 我并没有反对这些基本步骤有什么不对(我平时也是这么做的), 我们现在讨论的是在测试代码可以编译之后(也就是写完实现代码的stub后), 我们要不要运行测试,看它是fail还是成功, 还是直接去写实现代码.

请注意,我说的下列情况都是指测试编译之后(不要再误解了:)).

我也并没说gigix一定是错误, 我只是觉得他太绝对了.我觉得有时候我们能肯定测试代码一定会失败,这时我可以去直接写实现代码.有时我们为了试验一些想法, 我们想让计算机告诉我们结果;有时运行测试看我们的测试是不是写错了, 这些时候我觉得先运行测试是有益的.