* 理解用户真正想要什么了吗？真正的需求已经清楚了吗？  答：不清楚？ 那么请回到需求分析人员那里问清楚。 * 这个接口合理吗？ 如何验证其合理性？     答：先用TDD从最外层的需求构思这个接口（方法名，参数，返回结果） *  为什么测试如此难写？  答：从功能需求驱动测试代码的编写，何来如此难？ 如果果真如此，那是否可以细分需求呢？ * 一个需求的功能如此复杂，如何让测试尽快通过？ 答：小踏步前进。 不要太大胃口。 * 随着测试的增多，代码的完善， 感觉代码有点bad smell,该如何？ 答：任何时候你都可以放心立即重构，只要你从前面一步步用测试驱动走来。重构的影响总是在“测试“的自动监控下。 * 奇怪，XP不是宣称尽量使用接口 然后mock吗？ 怎么随着mock行为的增多而导致测试代码越来越复杂了呢？     答 :  请尽量不要使用mock,除非你认为非常有必要。 可以用一段代码一个类来做的事情，何必需要一个mock ? * 何时需要 mock ?    答: 很难回答这个问题，具体问题具体分析。但是记住mock的几点主要用途：             # mock是用来隔离你写测试的时候不能“关注“的功能部分,比如别人待实现的子模块，网络连接部分，第三方库的接口。                         # 如果该mock是待实现的功能模块，则测试的MOCK的目的还在于“推导出“对该功能的“接口推导“作用。             # 关于MOCK的行为，多发一些牢骚吧：         {  如果Mock的功能依赖于团队中别人待实现的功能A，请尽量减少你的代码的逻辑对该功能A地依赖程度             @  你期望 功能A来改变你的数据状态，并且你后续的逻辑依赖于这个状态的改变。 那么这样的依赖                 是“被警惕“的依赖，或许，这个功能A地实现应该划分到你来实现，而不是让别人来做。因为                 你的代码就是在做功能A的部分。 为什么存在这样的结果呢？ 源头或许就是 当初功能分的太细了？                 或许，详细设计还是 来得少一些为妙。             @ 你的代码仅仅调用功能A的接口来做一次期望的动作，后面的逻辑并不依赖于功能A所作的动作。（除非异常）                 这样的依赖是可以被接受的，也说明功能力度粒度的划分是合理的。              } * 如何验证测试成功？ 也就是算是完成了用户的需求？     答：尝试从用户的角度来考虑 “通过“的概念。         如果表示成功的验证太过复杂，那么就请思考一种更好得更简洁的验证方式。 * 为了让测试通过，需要分出一些proteced/private的方法来实现功能，这些新增的方法我还需要单独测试吗？     答：不需要，如果需要那么测试力度太低，测试代码严重依赖于功能实现的内部逻辑。而这些内部逻辑不应该反映在以测试驱动的测试代码中         ，这种严重的依赖也导致 重构很难进行，因为重构就意味着调整程序的内部结构，程序的内部结构调整，意味着             依赖这些内部功能实现的测试代码也需要调整。这样的工作量不是重构可以接受的，这个结果说明                 “为测试而测试“的严重后果。 * 那如何保证我新增的代码得到测试覆盖呢？     答：冒烟了。 * 测试如何才算足够呢？     答：代码里面的每一个边界情况，每一个可以设想到边界输入。 可以考虑到的逻辑没处理到的边界输入情况，任何一个bug都有     对应的测试覆盖到。 * 如何让测试深入每一个开发人员心里呢？     答：告诉他，不会写测试的说明还没真正迈入 高效率开发的大门。或者打击他说：不会写测试的就不算是入门(有危言耸听的嫌疑）。 * 如何在项目里面保证测试的进行随着项目的进行演进？     答：必须明确一个原则：每一个需求点都有单独的测试覆盖到。 * 如何让测试的编写成为强制的制度？     答：每个开发人员需要认识测试的重要性。用自动化的集成工具 保证这种制度能够成为一种“强制“。邮件通知，每日失败通告...。

声明：JavaEye文章版权属于作者，受法律保护。没有作者书面许可不得转载。若作者同意转载，必须以超链接形式标明文章原始出处和作者。
相关文章：   Adobe团队开发：增量开发那么好，何乐而不为？   困惑的结对编程？