JUnit·单元测试·TDD·流程建设

总听人讲JUnit如何如何，还以为是什么不得了的东西，拿来一看，不过如此而已，就是个单元测试的外壳而已，往里面各个空着的的格子里塞上自己的东西，就可以做单元测试了。原来老朽又是吃了名相的亏，其实这个东西的大体思路，实在是简单的到了极点
JUnit的作用只是在于，强迫程序员在开发之初就去考虑程序的测试问题，换句话说，还没写出代码的时候，就要想到这段代码该怎么测，这个思路其实也是Agile的一部分（老朽对Agile一贯是嗤之以鼻的，尤其是在公司接受了相关培训以后。讲的全是废话，都是老朽平素自己就在做着的事情，如吞温水般的习以为常，居然还会有人把这个当成是什么高明的东西来推广和研究，其目的大抵不出“骗钱”二字。当然了，更可笑的还是，居然有那么多人趋之若鸭子的上赶着去学。这类老帖不计其数，就不多罗嗦了）。TDD本来也无所谓对错，这只是当程序员的整体水平越来越低的时候，不得已而设立的一套步骤和流程，希望可以让笨人少犯错误，至少是早点发现笨人的错误而已。不妨随手找来一段代码，看看它的思路到底是什么：
比如说，老朽在做PE61（http://projecteuler.net/index.php?section=problems&id=61）的时候，靠观察和归纳，得到了各个figurate (polygonal) number的通项公式：
P(i, n) = n((i-2)n-(i-4))/2，其中n>=3
可以由此而生成计算P的函数：
def p(i,n):
    res = 0
    if(3 <= i):
        res = (((i-2)*n-i+4)*n/2)
    return int(res)
那么对于数学素养好，对数字和数列敏感的人来说，它们的自信使他们可以在这个公式的基础上继续展开计算，而同时，良好的编程基本功也使得这个函数程序的正确性有了保障。然而对那些心里没底的人，则需要再做一次验算，以及对这个函数进行一番测试。于是，可以编程实现这个过程：
for i in range(0, 9):
    for n in range(1,6):
        print("p(",i,",",n,") =",p(i,n))
而这，就是所谓的单元模块测试，JUnit其实在做的，也不过就是这样的一件事而已。而如果我们在写p(i, n)之前就先写好了后面的这段代码，那么这就是所谓的TDD了
综合起来看呢，首先，TDD是给“相对”低级的程序员用的，至少，这些程序员的水平，低于当前模块所需要的水平；其次，这些程序员还没有自知之明，对自己的代码有过度的自信，而不进行单元模块的测试，或者是对测试技能掌握的不够（因为它们是“相对”低级的程序员），根本不知道该怎么测，或者测的不到位，于是就需要一套类似checklist的东西来检查它们的代码，以行为规范和规定动作的方式来强制他们进行最可能有效的测试
所以说呢，虽然我很不欣赏TDD的做法，但是我很理解为什么要有人研究出这么样的一套东西，并且这个玩意还能这么受欢迎。其实这也不过是“流程建设”大趋势下的一个小片面而已
现在的程序员，实在是鱼龙混杂，而且是鱼远远远远远远远远的多于龙，不管读没读过书，随便找一本“21天精通”读一读，就敢号称自己是编程的，这代码质量要是能好了才怪。所以才有人搞出了“软件工程”、“软件开发方法学”和“流程建设”等等这些，幻想能够让鱼们去模仿出少数龙的行为模式，从而达到大家都像龙的目的
呵呵，痴人梦呓耳