单元测试的噩梦

还是 认识和实践的问题
用最快的机器测试
我们就用 AMD4200x2进行测试

测试是个态度问题。不是听别人说需要写测试用例才写。只听到这么多好处，但是没有亲身体会，态度是很难改变的。
   
   写测试用例是个技术含量很高的技术。能写出不错程序的人不一定能写出好的简单的测试用例。如果某人说他的测试用例跑一次的十分钟，给我第一感觉是，你的测试用例写的很烂，如果换个熟手，绝对不会写成这样的。测试用例不是重构可以解决的，如果重构，按照马叔的作为，为你的测试用例再写测试用例，晕死。

    不知道谁能找到测试用例运行时间指标的东西。

TDD不仅是对你以前编程思路的改变，可能连做项目的流程也会改变。

我认为，应该是用最简单的的程序做单元测试，整合测试可以用最快的机器测试。



我记得在某本讲用开源软开发的书里提到过，单元测试的运行时间掌握在2-3秒。

单元测试是开发人员做的，为的是方便重构，以及保证单个程序接口的健壮性。
这跟测试人员做的各种测试是不一样的。不要搞混了。

综合看起来，实际上gigix和Somerset等的分歧关键点在于测试成本和时间。
要达到gigix的要求起始很简单，加大成本
使用独立的最快的机子来做测试（专门编译机和测试机），不要使用人工干预，每隔一定时间测试(时间间隔大于编译时间＋测试时间)。每次测试结果email到项目成员。
开发人员就是写代码和写测试代码。但是一旦发现问题就要马上停下来改正。
开发环境设置好，问题就不大了。如果都是开发人员一边开发一边测试，那么就有问题了。大时间块都给切细了，就没有办法做好工作了

如果开发人员不是一边开发一边测试，那问题才大呢。

难道开发人员就应该一直闷头写程序，根本不去考虑自己写的代码是否正确，而把这个责任全部推给测试人员吗？真不知道是从什么地方得来的这种奇怪的观念啊。

如果我的team能把一半的时间花在单元测试上，我会非常高兴的。但他们就是不听，真是可恶啊。