主题：【原创】闲聊敏捷编程——测试驱动开发（一） -- 代码ABC

UI测试是一个难点，我个人的做法是将UI先抽象成输入/输出模块，然后用Mock技术模拟UI操作完成非UI部分的测试。到具体的UI部件则使用控件技术将复杂UI分割为简单模块，可以覆盖大部分UI功能。最后使用LoadRunner之类的东西做传统的功能测试（黑盒）实际效果是95%以上的代码可以在白盒内完成测试。

我个人不喜欢框架，在不得不用框架的时候我会把框架作为一个软件包。通过Adapter，FADE之类的东西封装一下。把我的代码和他们隔离，只做自己的代码测试。

测试覆盖率其实和你的开发方法有关，一定要记住TDD的一个原则——让未完成的工作最大化。覆盖率不够经常是由于预先设计引起的，这些设计使得程序员忽略的一些必须的测试用例——他认为代码中已经实现了不需要测试。这个原则其实是最难把握的，没有太好的方法。只能在实践过程中慢慢领会。同时XP的结对编程可以在很大程度上缓解这个问题。无奈，结对编程也是一个不太容易掌握的方法。同样的问题也会造成重构的麻烦，在TDD中重构是在每实现一个测试后进行的，也就是你必须保证你的代码一直处于合理的设计状态。

敏捷说起来很好，但实践起来并不容易。由于其中的东西是一环扣一环的，你说的很对，单看其中一个实践其缺陷都很明显，但是这些缺陷都会被其他实践覆盖。而反过来的意思是只要你有一个实践不做，就可能引起其他实践的缺陷。

不懂范式的DBA我见多了（这句话在河里说，恐怕要挨砖）我在讲数据库优化的课程里，下面坐的都是N年的DBA，能说出来的不到一半。