测试语录
昨晚看了一些关于tdd的文章，很有感触。
有一个聪明人提出了软件熵（software entropy）的概念：一个程序从设计很好的状态开始，随着新的功能不断地加入，程序逐渐地失去了原有的结构，最终变成了一团乱麻。
有些代码已经混乱不堪了，可是我们为何不去清理它们呢？我们担心会破坏它们。但如果我们拥有测试，我们就有理由确信这些代码不会被破坏，或是说我们可以很快的就找到被破坏的地方。
如果我们有了这些测试，我们就对代码发生改变无所忌惮。如果我们看到混乱的代码，或是一个不清晰的结构，可以毫无顾虑地清理它。
因为有了测试，代码重新变得易修改了；因为有了测试，软件重新变“软”了。
如果你曾有过增加单元测试到一个可以工作的系统中的经历，你会发现那一点儿都不好玩。你很可能会发现想跑通测试，你一定是要么去改变系统中的部分设计，要么就在测试上作假。这是因为你试图去测试的系统并不是基于可测试设计的。例如，你想要测试某个函数f。然而，f调用了另外一个从数据库中删除记录的函数。在你的测试中，你不希望这条记录被删掉，但却没有办法来阻止它。这样的系统就不是基于可测试设计的系统。
当你遵循TDD的三条规则的时候，你的所有代码天生就可测试！而且另一个能形容“可测试”的词汇就是“可解耦”。为了单独的测试一个模块，你就必须把它解耦。所以TDD强制你去解耦这些模块。确实，如果你遵循这三条规则的话，你会发现你可能比起从前来能做出更多的解藕。这就强制了你去创造更好的，低耦合的设计。
一旦你有了一个测试，你就要一直确保其正常工作，以检验你所加入的新的工作代码。不要每隔几天或最后才运行测试，每天你都应该运行一下测试代码。这种投资很小，但可以确保你得到可以信赖的工作代码。你的返工率降低了，你会有更多的时间编写工作代码。
使用JUnit后，花在调试的时间就会更少，在改变代码的时候更有信心。有了这种信心，你可以在重构代码，添加新特性的时候更有闯劲。如果没有测试，那么重构或者添加新特性很容易成为妄想，因为你无法知晓什么地方会被破坏掉。如果拥有完善的测试套，在改变代码后，立即运行测试，这样就可以得到信心，你的改变没有破坏任何东西。
当运行测试时，如果检测出bug，因为代码在脑海里还很清楚，所以bug很容易被解决。用JUnit编写测试，可以使你的代码编写达到极限速度，而且快速定位bug。
单元测试通常不测试很简单的代码，一般也不测试“边界代码”。很简单的代码容易理解，例如Get/Set函数，这里解释一下“边界代码”。“边界代码”是指用于与外部系统交互的代码，例如用于处理用户界面的代码。数据库、文件、网络都可以看作是外部系统，用于读写数据库或文件、或访问网络的代码也可以看作是“边界代码”，这类代码应该独立出来，可以进行单元测试，但对这些代码的单元测试通常不能自动验证预期输出，而是需要人工察看。编程时，不要把普通代码与“边界代码”混在一起，例如，不要把各种运算直接写在界面类中，做到了这一点，绝大多数代码都可以进行单元测试。
飞涛软件工作室
2006-09-30 08:19:12
Warning: MkDir failed (Disc quota exceeded) in /z1/18ie/public_html/count/html/count.php on line 12
Warning: fopen("/z1/18ie/public_html/count/html/2008_07/06_every.txt", "a+") - No such file or directory in /z1/18ie/public_html/count/html/count.php on line 42
Warning: Supplied argument is not a valid File-Handle resource in /z1/18ie/public_html/count/html/count.php on line 43
Warning: Supplied argument is not a valid File-Handle resource in /z1/18ie/public_html/count/html/count.php on line 46
Warning: Supplied argument is not a valid File-Handle resource in /z1/18ie/public_html/count/html/count.php on line 48
Warning: Supplied argument is not a valid File-Handle resource in /z1/18ie/public_html/count/html/count.php on line 49