测试驱动开发( TDD ) 常见疑问

（免责条款，以下回答基于笔者个人理解）

1. private 方法怎么测试?
   public 方法都覆盖到了就行了。


2. Tdd 算 UT,还是算 IT?
  (我发现QA对于这个区分比较在意)
   TDD 是 Test Drive Development, 能驱动开发就行，
   只要这个test让你对代码放心，不用管它UT还是IT。

3.  测试代码和工作代码比例是多少，覆盖率要达到多少？
     让你对代码觉得放心就好，这些不要管它。

4. 是不是要水平比较高的开发人员才能实行TDD方法？
   从实践效果来看，从新手到高手都适合TDD。
   如果觉得不得要领，需要找个已经熟悉TDD的人和你结对编程。


5.  习惯了TDD后，不用TDD时的开发能力会不会降低？
    -_-!，只能说TDD使人将开发能力提高了。


6.  项目时间紧任务重，能实施TDD?
    就没见过时间不紧任务不重的实际项目。
     干TDD就是为了省时省力。

实际情况是，使用这种开发方式的人还是很少，主要是观念问题，一般试过了都觉得这种方式不错。

对于Web应用，很多人说过Action测试很繁琐，没必要。或者使用selumium这样的工具进行IT。

我不知道拿到一个任务时，你们是如何起步写测试方法的？ 同学们分享下经验啊

如果不写测试那你第一步做什么？

如何起步写测试，从哪儿开始？

我的想法是从界面开始一层层往下剥，一直到数据库为止。

在CMMI 2中就有规范，Test Case的覆盖率应达到1界面1个，或1类1个。


我认为团队里如果有新手，最好由高手写Test Case，因为，这需要有对功能、代码、实现结果的全面掌握的能力。


非常同意。我正在新公司第一天就接手了一个同事两周赶出来的一个约4万行从未运行过的业务系统，使用TDD先对着需求把Test Case写了出来，现在Test Case/Fix Bug/Coding同步进行，本来需要3个人的项目目前我一个人已经输出自测无bug的30%模块。一些约束异常与性能的Case可以及大的提升code质量，要知道，一个开发人员70%以上的时间都是再与Bug战斗。除非把Build成功当成完成（我认识的绝大多数开发人员都这么想）。

我在问你呢
如果不写测试你第一步做什么？
回答了这个问题你就知道该怎么起步写测试了。