From: laofo 在强调单元测试覆盖率达时候，我一直有个疑问：单元测试要做到什么程度？
另外一个问题：在一个产品的研发过程中，我们有多长的时间去写单元测试？
- 记住，功能测试是真正对用户有意义的测试。单元测试只是为你—开发者—服务的。属于奢侈品。如果你有时间去写单元测试，那最好了：当你的程序出现问题时，它们能帮助你省去很多时间。但如果你没有时间，你要确保功能测试能覆盖到你的产品里用户所期望的所有功能点。
看到上面的话，我觉得比较靠谱。
From: Brian 除非真的有足够时间和 resource,或者使用 TDD， 否则到最后效果都不会很好… 更严重得是，写完之后维护的问题，就跟写文档一样的…
写单元测试没有自动化测试靠谱
From: Dan 在写代码的时候顺手写单元测试用例最好了 时间浪费的其实不多 …
From: Eric 单元测试跟自动化测试是两个对立的概念吗？感觉单元测试也是自动化测试，只不过目标较小
From: Brian 我说的自动化测试是侧重于功能上的自动化测试，单元测试跟它没有必然联系，我的意思是，如果在这两者中选择的话，我会选择花时间开发自动化测试，而不是单元测试
From: Eric 个人觉得，项目如果不是算法密集型的，单元测试意义不大。(对一堆 UI 进行测试可谓费力不讨好) 对较复杂的算法还是应该进行彻底的单元测试。
From: Adam
大项目，组件级开发，单元测试还是比较重要的，不然最后集成的时候，代价可能比单元测试成本还高。
From: Brian 恩~~ 应该采用混合策略，不能一刀切所有都要单元测试或者所有都要自动化测试
From: Adam “测试到暴露出来的接口” 比较合理，但对于有些 class 和方法如果是关键的地方做单元测试也很有必要。 “应该采用混合策略，不能一刀切所有都要单元测试或者所有都要自动化测试”，这个更 make sense.
From: Brian 有时候写单元测试还是很花时间的，而且不是说写完了就完事了，以后代码改了，还得去更新相应的 case，不然到后来，单元测试就都 out of date 了~
在大多数项目 schedule 都很紧的情况下，写单元测试还是很难完成的，主要是时间和 resource 问题~
From: HC 要不要单元测试，覆盖率如何实际上和组织的开发习惯很相关的。 经常是这样在开发阶段计划出 30%-50% 的 effort 去做 unit test 被认为是不可接受的。 但是，到了项目后期，一遍又一遍的 regression test, bug fixing, new
bug introduced, new bug fixing. 最后实在不行把部分 “低优先级的” feature 去掉以保证按期 release. 这种情况认为是不可避免的。
From: Brian 不采用 TDD，而是事后写单元测试，不见得就能对产品质量产生很大影响… TDD 可以很好的改善产品质量，但是单元测试就不一定，特别是应付工作式的单元测试，你怎么能保证单元测试本身的质量呢~
去十渡玩的时候，听说 yamazaki 最近在做这方面的改进，所以贴一些我个人认为比较靠谱的讨论，希望对 yamazaki，也对大家有用。
感谢 laofo~~~~学习 ing
单元测试可以理解为微观测试，所以仅限于本地的，模块内的测试。任何通过网络/数据库/系统环境变量才能完成的都不属于单元测试。
单元测试为了能作为自动化测试一部分，一定要小巧，快速执行。
测试的覆盖率和通过率一样重要。
单元测试的测试覆盖率和通过率的确很重要。通过率就不用说了，对于测试覆盖率的标准，不同的项目和不同的测试目标应该有不同的标准。比如有的项目 30% 的覆盖率就已经很好了，但是有的项目 60% 都还不够。所以要针对不同的项目设定不同的标准。
举个比较极端的例子：一个 30 人天要完成的一个 flash 开发的项目，单元测试覆盖率要达到多少？这个的确很难设定基准。如果一个公司做类似的项目很多，积累了大量的历史数据，从中就可以针对自身的项目确定一个比较合适的标准。如果是一次性的，又没有业界标准（即便有也不一定适合这个项目），则标准很难确定。
公司几个存储相关的产品模块，总是在后期蹦出重大问题，现在开始强调单元测试，要求 100% 的覆盖率。
还是要看项目，看投入产出。