1. 写UT时还无代码实现，但要包含对外的接口，这时就有设计，这里就将开发融合到了具体场景里去了，而在传统的开发模式中，服务接口前期并未直接参与到具体场景，都是完全实现后的再调用，凭空设计的风险就要大。
2. 传统的设计,可以说是based on assumptions and experiences.
敏捷的设计,可以说是based on fact and usage.
传统的设计,可以说是refuse change.
敏捷的设计,可以说是embrace change.
敏捷的设计,可以说是based on fact and usage.
传统的设计,可以说是refuse change.
敏捷的设计,可以说是embrace change.
在作一些需求非常明确,一定不会变化的项目的时候,传统的设计方式可能会比敏捷的方式更有效率.
3.根据需求 能否直接写出单元测试用例？
我的看法是不能 单元测试必须在类的基本结构确定之后才能写出来，否则就不能称为单元测试了。
我的看法是不能 单元测试必须在类的基本结构确定之后才能写出来，否则就不能称为单元测试了。
所以我认为总体设计还是要先行，不过可以不用完整的设计，这个也是迭代的，需给出总体的架构和重要需求的概要设计，具体的设计则是测试驱动。
4. 测试从何而来。这一点我是赞同测试必须从需求来的。这才是敏捷的风格，敏捷开发与传统开发的理念上的根本不同就是敏捷的目标是完成需求而不是合同。既然用某个东西来驱动开发，则这个东西必然要从目标而来。目标是什么？传统的瀑布开发，每一步的目标都是承上启下的。测试阶段的目标是修正编码的错误。所以测试的目标很明确，是验证。敏捷则不是。
敏捷有一个很重要的原则：“可以工作的软件是进度的主要度量标准”。所有的敏捷实践中，无论是怎样的进度控制，其评价标准一定是“可以工作的软件”，而不是某个阶段性成果。换言之极端点说，就算是所有的单元测试用例都已经写好在我看来等于什么都没有做。因为并没有可以工作的软件。没有可以工作的软件，就无法评价你的工作成果（所有的测试用例）是不是符合最终目标的。
很多人认为，TDD的目的在于保证代码质量。我想问题应该不在于此，如果只是为了保证代码质量，Test在前在后是没有关系的。如果要将TDD与敏捷结合起来看，我觉得TDD是为了确保设计的简单这会比较靠谱。（或者，我大胆的猜测下，存在两种TDD，一种是敏捷的，一种是非敏捷的。毕竟TDD出现在敏捷理念流行之前）
或者说在敏捷的范畴里，TDD是一种“简单——尽可能减少工作量的艺术”。
为什么？
我们来看看如果不是TDD的话，我们会怎样来开发。
显然我们会先将需求抽象建模，做出需求的抽象模型，然后实现这个抽象模型，再加上血肉交付产品。这样做的理论依据也是很充分的，需求随时可能变化，但抽象的东西不会变化。
问题是这个抽象是需要时间的，XP的实践是什么？客户就站在身边，试想客户有时间等着你去做对他而言很无聊的抽象建模么？
甚至于，客户自己都不知道自己想要什么，或许他会给你一个方向，我要一个博客，结果在做的过程中你发现他要的其实是一个SNS或是别的什么东西。这样，你的抽象建模就变得毫无意义。
如何在最短的时间内完成可以工作的软件呢？唯一的办法就是keep simple!我们的目标是什么？可以工作的软件。完成这个目标的评判标准是什么？那不就是测试。
或者说我们不应该将问题分解成，完成客户的需求 = 首先根据需求作出详细的设计，根据详细的设计作出详细的单元测试，如果程序能够完成单元测试，则我们完成了客户的需求。这个过程太冗长了。
而应该是我们完成可以验证满足需求的东西（测试）。然后让这个东西say OK。
敏捷有一个很重要的原则：“可以工作的软件是进度的主要度量标准”。所有的敏捷实践中，无论是怎样的进度控制，其评价标准一定是“可以工作的软件”，而不是某个阶段性成果。换言之极端点说，就算是所有的单元测试用例都已经写好在我看来等于什么都没有做。因为并没有可以工作的软件。没有可以工作的软件，就无法评价你的工作成果（所有的测试用例）是不是符合最终目标的。
很多人认为，TDD的目的在于保证代码质量。我想问题应该不在于此，如果只是为了保证代码质量，Test在前在后是没有关系的。如果要将TDD与敏捷结合起来看，我觉得TDD是为了确保设计的简单这会比较靠谱。（或者，我大胆的猜测下，存在两种TDD，一种是敏捷的，一种是非敏捷的。毕竟TDD出现在敏捷理念流行之前）
或者说在敏捷的范畴里，TDD是一种“简单——尽可能减少工作量的艺术”。
为什么？
我们来看看如果不是TDD的话，我们会怎样来开发。
显然我们会先将需求抽象建模，做出需求的抽象模型，然后实现这个抽象模型，再加上血肉交付产品。这样做的理论依据也是很充分的，需求随时可能变化，但抽象的东西不会变化。
问题是这个抽象是需要时间的，XP的实践是什么？客户就站在身边，试想客户有时间等着你去做对他而言很无聊的抽象建模么？
甚至于，客户自己都不知道自己想要什么，或许他会给你一个方向，我要一个博客，结果在做的过程中你发现他要的其实是一个SNS或是别的什么东西。这样，你的抽象建模就变得毫无意义。
如何在最短的时间内完成可以工作的软件呢？唯一的办法就是keep simple!我们的目标是什么？可以工作的软件。完成这个目标的评判标准是什么？那不就是测试。
或者说我们不应该将问题分解成，完成客户的需求 = 首先根据需求作出详细的设计，根据详细的设计作出详细的单元测试，如果程序能够完成单元测试，则我们完成了客户的需求。这个过程太冗长了。
而应该是我们完成可以验证满足需求的东西（测试）。然后让这个东西say OK。
5.有句话叫做“不要把解决问题的方案，当成问题本身”－－《你的灯亮着么？》
先写代码再写测试，就很容易把对“要解决的问题”的测试，写成对“解决问题的方案”的测试。（这里要解决的问题，不一定是需求的问题，可能是写一个string.trim方法来去掉前后空格）最后测试验证的是“方案“本身是否符合你当初对”方案“的期望，而不是验证”方案“最终是否解决了”问题“，这个才是你真正的期望。
先写代码再写测试，就很容易把对“要解决的问题”的测试，写成对“解决问题的方案”的测试。（这里要解决的问题，不一定是需求的问题，可能是写一个string.trim方法来去掉前后空格）最后测试验证的是“方案“本身是否符合你当初对”方案“的期望，而不是验证”方案“最终是否解决了”问题“，这个才是你真正的期望。
6.我们该如何为一个私有方法作单元测试呢？我以前也想在博客上讨论这个问题，但是最终不知为何没有进行。我的看法是，如果设计得当，每个类的职责单一，应该不会出现需要进行单元测试的私有方法。如果一个私有方法需要测试，那么说明它的逻辑相对较为复杂，而且有独立的职责，应该将其提取到外部的类型中。
7.在很多情况下，对于具有一定业务性的功能，需要得到各方面资源的配合和准备才能完成的测试，这时候如何来实践单元测试。如果这种情况不进行单元测试，如何来保证项目中，业务逻辑部分代码的正确性？
再往具体点说，我们使用MVC在开发时，我们可能会对Controller进行单元测试，那么Controller势必就是一个业务功能点，那么就不可避免的与数据库等资源交互。这种情况如何来隔离外部资源对单元测试的影响？
再往具体点说，我们使用MVC在开发时，我们可能会对Controller进行单元测试，那么Controller势必就是一个业务功能点，那么就不可避免的与数据库等资源交互。这种情况如何来隔离外部资源对单元测试的影响？
答：如果Controller包含业务，或者比较复杂，可以抽取出service层，对service进行业务方面的测试，对controller进行页面级逻辑测试。如果需要访问数据库，创建接口，用mock模拟数据访问来测试service。如果离了数据库就无法测试业务逻辑，说明业务逻辑在数据库中，那么应该测试sp或者数据库。
所谓的需要多方面配合的测试，其实就是集成问题，应该进行集成测试。单元测试不是万金油。 如果集成中还有逻辑，那就mock掉所有的集成点，集中测试这一点逻辑。
