对于design，当前我们存在这样的问题：test code够不完善，有bug不好发现，发现了不好定位，改完了可能引发其他问题而test code能够跑过。 这个想想以前定义的关于“root cause”和“code coverage improvement”的story应该可以了解。

  Fitnesse用于regression testing, daily-build integration functional testing 会在一定程度保证quality的基础上提高team的效率。对于design, 写test有时比较无奈：进度压力，quality要求。 这里“进度压力”不是解释一切问题的套话。

  对于design， 我们写UT、FT最终是为什么？是不是所有的source code都要用UT覆盖？这个问题不做讨论。下面的内容的前提是：source code会被覆盖，但不一定都是UT；quality会在一定程度上保障，但不一定是追求的code coverage。

  我们目前使用的Fitnesse，test时会run我们对外功能接口，与我们目前在test中写的很多测试方式类似。大胆的设想一下，我们把当前test里的某些test由Fitnesse代劳会怎么样？大家肯定会有很多担心，注意我们这样做需要几个前提重要的条件：
1. code要简单易测试， 将业务逻辑code与common code区分开，定义合理的对外接口，这个接口不等同于我们目前在code中定义的抽象的interface，我们可以从TDD的角度理解为是为了run过测试写的接口；
2. 对code写“必要”的UT，构造合理的输入参数，测试各种边界条件；
3. design与test保持沟通，Fitnesse的case要保障。

  当然，做到以上几点，即便不借助Fitnesse，quality也能保障，但做两次functional test需要考虑。从以往的经验来看，design与test的协同工作，出现issue的数量会小的多，其中原因大家很清楚。从当前行业状况来看，出于响应变化的考虑，严格的分阶段分过程的做法是值得商榷的，等待一切都OK再开始的做法很难操作。有点跑题了，回到design上，quality不是只体现在数据上，追求数据可能会让数据没有太多有效价值，非左即右的做法不可行，如何更好，我们一直在探索与实践。