《Agile Web Developments with Rails 》的Part II 看完一遍了。对于设计和测试的辩证关系也有了更深入的认识。
常常有听到，TDD的高手说，如果没有了自动测试，编码将无法想像。这和我们现实中，对自动测试编码厌倦和应付的态度是截然相反的。
虽然我相信那些高手说的都是真的，但现实中我确实还未有这种感觉。如何在现实中去扭转，也常常是不得其要领，草草了事。
不过和高手交流多了，加上最近看过了RoR的书，实践了RoR对增量开发的天然支持。发现有些是自己曲解了，需要整理一下。
对于自动测试，在我看来，现实中的有三个层次：
第一个层次，就是为了JUNIT而JUNIT。
这一个典型例子，就是泛滥的数据库CRUD测试。这种JUNIT的测试Source，甚至可以批量生成。Case的数量是上去了，但是含金量高，有价值的Case很少，对于Bug摘出作用也微乎其微。但是依然有其价值，
一是，不需要多高的测试能力，随便一个人，看上几个Sample就立即得心应手。
二是，对于那种测试看都不看，就稀里糊涂的划上OK的责任心淡泊的开发者来说，是一个杀手锏，因为起码他得把测试Code跑通的。
三是，Case数量和Cose覆盖率都可以很容易提高，也好和客户交差。
第二个层次，是为了摘出Bug而JUNIT。
我觉得我就处于这个层次。我认为，编写测试Case没有灵丹妙药，它必须在分析当前功能的基础上，有针对性的作出适当的Case。所以我常常和开发者说，如果你都认为这个Case写了和没写没什么区别，你就应该删除掉，应该写出你觉得最会有可能出Bug的测试用例。不过，现在看来，即使这个做的多么的完善，依然不是最高层次。因为常常现实中，会遇到想到了一些Case，却无论如何写不出，或者是非常的费工夫才能写出相应的自动测试Code。
第三个层次，是为了更好的实现JUNIT，而在最开始做好设计。
这个设计，主要针对的是系统框架，程序结构方面的设计。上次一个技术达人过来提出一个概念“一个Class只做一个业务方面的事情，一个Method只做一个单纯功能的事情”。道理浅显易懂，其实除了程序结构清晰，易读易维护的好处外，它还切切实实地提高了单体测试Code的编写的方便。现实中有一个普遍现象，一个坏的程序设计的作者的自我扭转，并不是开发中自觉的不断重构，而是在编写自动化测试的时候，被逼无奈只能去改进设计。这种不断改进的结果，反而产生了，一开始就认真做好设计，中途勇于重构的良好设计开发习惯。所以到了这个层次，设计，开发，测试都会取得完美的统一。而TDD，在这个时候就变得很自然了，因为测试已经能驱动所有的工作。
对于第三个层次，很难用单纯的测试改进来推动，他需要一个开发者更高更强的综合的实力。而在Rails框架中，这些已经不是选项，而是必须。从第一个自动做成的Template开始，它就为你添加了Functional和Unit两个层次的测试框架，并且生成了一些显然，自动的测试用例。Unit这个层次，主要着眼在Model的逻辑上，对于每一个Check，变换，计算等的逻辑方法，都可以添加适当的测试。而Functional则是对页面间的迁移，表示做了测试。Functional测试，要比Unit测试要更加难以建模。通常用人眼睛看来很简单的确认，比如UI测试，要建模成测试程序，常常非常的困难。所以了解一些通常的测试模式，是有必要的，比如根据某一个Table的TR的个数，来确认检索出的结果确实符合要求。
从这个测试引申开去，其实在开发中很多问题都会有同样状况，发生问题的地方，并不是真正产生问题的所在。
之前，包括我在内，很多人对ORM工具都有一种既爱又恨的感觉。对于它的优点自不必多说，在大部分通常业务上，常常事半功倍。但是现实中有太多太多的不那么通常，这个时候ORM工具有常常是事倍功半。问题在哪里呢，是ORM工具的问题么，甚至导致现在有很多人倾向于更加轻量级的ORM，让复杂的事情回归自己的控制。是如此么，其实我觉得不然。之所以会有这些所谓不通常的Case，并不是必须如此，而是因为DB设计的不合理，业务设计的不合理所致。看过Rails的实践后，我有一种感觉。就是ORM工具的使用，有两个路线。一条是完全通过设计修改DB，来自动生成对象。另外一条是，根据设计的Model来反过来生成DB。在最初，这两条路，都是一样的，但是随着项目的进行，前者更容易导致，设计越来越倾向关系数据库，而对象只是副产品。于是，发展下去，自动做成的对象变得越来越不适用，需要大量的手动修改，到最后，会感觉ORM只要能把DB的Table自动做成一个Entity类就可以了，其他的制约，扩展等等，全部自己手写更方便。而第二条路线，就是RoR教给我的，这常常以OOP的Model为核心，而DB只是其附属。无论如何怎么发展，自始自终都是一个纯粹的OOP。这样，ORM也会一直保持适用。
所以，软件开发本身就是一个相互制约，相辅相成的一个完美系统。遇到问题，不去纠结其本身，站得更高些，也许能看到全部。这也就是开发的艺术吧。