请来认识敏捷开发。

* 理解用户真正想要什么了吗？真正的需求已经清楚了吗？

 答：不清楚？ 那么请回到需求分析人员那里问清楚。


* 这个接口合理吗？ 如何验证其合理性？

    答：先用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都有
    对应的测试覆盖到。

* 如何让测试深入每一个开发人员心里呢？
    答：告诉他，不会写测试的说明还没真正迈入 高效率开发的大门。或者打击他说：不会写测试的就不算是入门(有危言耸听的嫌疑）。

* 如何在项目里面保证测试的进行随着项目的进行演进？
    答：必须明确一个原则：每一个需求点都有单独的测试覆盖到。

* 如何让测试的编写成为强制的制度？
    答：每个开发人员需要认识测试的重要性。用自动化的集成工具 保证这种制度能够成为一种“强制“。邮件通知，每日失败通告...。


 

       

firebody 写道：


持续集成只是频繁的跑单元测试来发现问题，如果他不写测试也没辙

的确，持续集成应该是建立在详尽的Test suite基础上的，重构也是一样，单元测试是基础，是摩天大楼的基石.

daquan198163 写道：



test coverage report

敏捷咋就成了测试了泥？

几乎所有的敏捷原则都依赖测试，自动化测试是敏捷的前提和基础。

虽然测试只是敏捷开发的一个方面,但是确实太重要了,但是要严格的执行它却不简单,我发现主要问题貌似解耦和综合的矛盾,哪位同学很艺术的解决了这个问题?

要有主见
  外国老说啥就是啥，
  书上说啥就是啥
   这样不好

  有些问题不好解决，可以避开嘛，其实也没传说中的那么重要
          心要宽，眼要阔，要转变思路

从偶然走向必然,重要不?