测试写到什么程度算足够？

足够的定义：

 
  1）贴近需求的测试
  2）如果逻辑比较复杂，可能需要考虑多一些边界情况。


毕竟开发功能的人员不可能全力以赴地进行测试来保证功能针对每一个输入情况的准确反馈。
更何况，一些特殊的输入情况的反馈也需要需求的深入分析。 功能质量的全面测试有QA来保证。

对于开发人员来说，重要的是他写测试的目的是什么：
测试对于功能实现开发者来说，有几点需要保证：

1）保证需求的实现 在测试里面得到反映

2） 保证对重构提供的足够的支持

真是寒自己一个。在测试先行的今天，我们公司还是要求我们写main()来进行测试。

   许久没有上来了，最近忙着给新入职的同事做培训，刚刚好，涉及到单元测试这个话题。
   首先，我将楼主的范围人为限制在单元测试下吧，这样容易讨论，也估计是楼主想讨论的。
   我们应该弄清楚什么是足够。在不同条件约束下，对于足够的理解是不同的。不过，我们至少可以说或者清楚，在一般商业系统的开发下，单元测试的足够标准其实是可以确定的。可以这么说，足够就是你需要做更深入或者详细测试从而发现问题的成本大于你的限制成本时，那么，我们认为它就是足够的了。简单讲，就是你需要做单元测试所花费的人力和时间成本高于在这阶段发现问题的价值时，那么单元测试就足够了。或者，也可以说，当你的任务计划不允许你做进一步测试，或者你已覆盖了一定比例的测试路径时，测试是足够的了。那么，这种比例是多少？这种成本的估算又是怎么来，这就要看具体的企业与系统目标，还有项目机会了。有的人也许提出质疑，但是谁都不能否认，做高精密控制系统、要求严格的金融商业系统、操作系统、广泛使用的公用基础组件以及普通的MIS和网站，它的要求是绝对不同的。
   TDD从来就没有错，但是，这种实践的一个不得不面对的问题是，它忽略了设计与实现的复杂性。实现一个逻辑，和穷举验证这个逻辑的确定性所带来的工作量相差是巨大的。每本推崇TDD的书似乎都很喜欢拿add或者div方法做sample。但是实际的业务方法又是何其复杂，试图在设计之初就去穷举测试路径是不现实的。
   那么，我们是否有可操作的实践那？当然有！一般说来，一个单元测试用例需要覆盖主要路径，分别就通过测试（1-3测试条件）、失败测试（1-2测试条件）、异常测试（1-2次测试条件）、错误测试（1次主要的测试条件）基本可以说，单元测试的工作是足够的，并且带来工作量的影响也是可以接受的。当然，另外一个问题就是测试数据的多样性。
  

   另外，对于dongbin的关于XP的理解，个人是不太认同的。首先来说，TDD与Pair Programming只是XP的实践之一，并非它的Principles或者是Core Values。不是说没有TDD和Pair Programming，XP就变了位，XP的核心思想在于沟通和敏捷。在我们学习和使用任何一种经验技术时，最忌讳的就是全盘照搬或者否定。TDD和Pair Programming在中国的实践并不好，自然有其原因的。我们需要做的是尽量找出其问题或者说冲突所在。

   兄弟，好的测试，不在乎你用的是Junit还是main，更重要的是你对测试的认同感，重视度，还有懂得怎么去测试。
    自然，懂得使用好的工具是一个优秀的工程师也需要具备的。