你们公司单元测试吗?

我看了各位的发言，主要是围绕在进度与质量，我们怎么把握进度，而又不失质量，我认为这两个东西并不矛盾。首先应该是你团队的开发人员“质量“怎么样，你的团队合作怎么样？

总体来说，最终归的是管理问题。
管理人员怎么在这个问题上把握，我觉得他应该有丰富的项目经验，对于上级的无理要求，他会拒绝，他认为。一切代码是完美的。

磨刀不误砍柴工！~
测试是必要的，如果你不能保证你写的每一个类都正确、每一个包都没有问题、每一次连调都顺利通过，那我佩服你，简直就是个代码机器！~
反之，没有一套测试用例，单凭眼睛去看，一顿logger.debue(""); ，如果是万条记录的筛选呢？你看得过来吗？
单元测试 你可以用 JUnit
测试数据库 你可以用 DBUnit
再不成 再加个 easyMock
测试覆盖率如何 cobertura
现在不是小作坊软件开发阶段，你开发一套没经过测试的东西给客户，有个小问题你就得全体出动，日夜赶工，连轴转都未必找得到错。这又是何必呢？！~

我们公司小，小到J2EE+J2ME+JSP总共就8个人，尽管如此，依旧写个类就写个Test。结果如何？！~从开发到Demo版本出来其中没有出过什么BUG，工期也正常完成。现在开发Alpha版本，我们很有底气说我们开发的东西绝对靠的住！~
给金融行业写东西，不测试？！~ 一个小错误，差出来的钱，难道你来背吗？

好的程序员--好的编码惯,好的职业素养,好的工作态度,好的学习能力!
每一行代码都可能出错,所以千万不要有侥幸的心理(记得捕获可能出现的异常,也不能有异常就来个Exception,具体点的好).
全部依赖测试也不好,任何东西得有个平衡点(编码时就要考虑各种情况,如:传入的参数是否正确,不能想"传入的参数肯定不可能大过这个值,或在什么范围以内",这样测试会减轻程序中的错误,重在业务逻辑上的测试,不知说得是否正确,还请大家指教!).

好的程序员一定有好的编码习惯,应该也重视单元测试,要对自己的代码负责,对哪一个类活方法不放心就写测试用例.我喜欢spring,除了它的很多很多优点之外,最重要的是它对我的TDD的影响,当你不知道某一个类或方法怎么去测的时候你应该可以从spring的测试用例中找到答案,当然其他的开源项目也是一样.其实看看我们周围,我们的业界,最优秀的代码一般都来自开源社区,而公司开发的很多很多都是质量地下的没用的东西.实施TDD的,好像多半也都是开源社区.

不好意思，这么久了，我把这个贴翻出来。
看了上面各位的发言，我发现我们公司里面做的其实就是面向单个功能的集成测试。
可能作产品的公司在进度上自由度大一些。
作项目的，如果市场人员和客户承诺了一个无法实现的进度，工程延期在我们这里，可是个很严重的事件。我们的作法是只好在进度和质量上搞平衡。说白了就是偷工减料啦。
    具体做法一般如下。在Online画面上，初步成形一部分页面后，大家一起来看外观有没有前后差异大的地方，有，就记下来。在各个页面上胡乱点来点去，找两三个人，专门给页面挑错。也根据个人的经验，进行逻辑的测试。实际上是部分的集成测试。但是不写测试用例，只记录错误现象。
    挑出毛病后，大家一起来改，保留一部分人马继续开发。然后，循环执行以上过程。
    如果是Batch程序呢，做法其实也差不多，就是尽量的造各种数据，看输出结果。
    然后，时间越来越紧迫，接近尾声了；在心里暗暗祈祷吧。实在没辙，时间太紧了，连续加班到半夜，周末也加班。一个月下来谁也受不了。

以前也不用测试开发的
今年开始在一个公司内组织开发
没有人会TDD开发
才是不用TDD的主要源因
为此我作一个DAMO
用了很大功夫才让测试跑了起来
大约一周时间
效率有一定的提高
主要还是质量提高很快
对于刚来的人来说上手很快。。。。

对于单元测试的看法：
缺点：
1、首先单元测试的工作量是要占整个项目1/3，对于项目周期短，时间比较紧的项目根本来不及
2、对于项目需求变化大，设计变化大的项目，单元测试跟不上程序的变化，往往到了项目的后期由于设计的具体变化，导致单元测试跟不上以至于整个单元测试在项目后期，有许多都用不上
优点：
1、最大的优点是通过单元测试可以规范程序员编码规则，提高程序质量。
2、对于复杂的逻辑测试，可以减少测试时间，较少错误调试时间。

如果是TDD
Q1:可以提高开发速度,你可以试试...
Q2:如果只是小改速度超快,你还是可以试试...
U1:不一定,我见过大多数人TDD之后很少重构....
U2:不会TDD之所以强就强大不能开发复杂逻辑...所以你必须KISS

1.写测试只是占用你的"正常"的测试时间，只会加快开发进度
2.需求变化，修改代码之前首先就应该修改测试，这才是 TDD

.NET怎么没有单元测试框架 NUNIT是什么,不就是.NET的单元测试框架吗??