单元测试由谁做？

单元测试由谁做？
注意：此不是问题，是问句，供有兴趣的朋友讨论。也欢迎提出观点和案例。

我曾经测试过一个不错的产品，测试用例写得很好，我的职责就是看着文档
点击鼠标，按照测试用例的要求检察必要的结果和log等。

很少测试出问题。

我测试一个产品，也不错，但是测试用例很简单，我的职责是分析用力到底写
的是什么，研究半天扩展出好多测试用例，然后发现好多个问题。发现很多
应该有程序员完成的任务，轮到测试人员发现。

问题多多。

单元测试在开发人员来看一般指的是Unit test，这也是在XP流行后边的流行。
但是单元测试古以有之。在测试分类中就有单元测试、集成测试等。

所以单元测试的单元在开发与测试人员来看大小是不一样的。好的开发人员
写出了比较大的单元测试，测试人员很少测出问题。测试人员的单元测试不能
涵盖开发人员的单元测试，但开发人员的单元测试却可以涵盖测试人员的单元
测试。

什么是单元测试？
对于开发人员：一般指利用XUnit系列工具，通过辅助工具生成或由开发人员
编写的用于测试类或接口的测试代码。一般使用产品开发语言来编写。

对于测试（黑盒）人员：产品的一个最小的用户可见或针对系统其他部分可见的功能。

单元测试究竟由谁来写，这个不是一个原则问题。虽然 XP 教材中推荐由开发人员自己来写单元测试，但是具体实施的时候可以进行适当的变通。

在《软件研发》第一期所介绍的 Symantec 那个有名的 XP 成功案例中，他们采取的做法是这样的：
让测试（QA）人员与开发人员结对，由测试人员来编写单元测试。开发人员把注意力更多地集中于编写功能代码。

他们这样的做法取得了很大的成功。后来他们得出的结论是 XP 不是不再需要测试人员，而是仍然需要大量的测试人员。而且 XP 对测试人员提出了更高的要求，至少你现在需要深入掌握 JUnit 等工具，你要充分理解功能需求，编写大量的测试代码。正常情况下，测试代码行数大约与功能代码行数相当（1:1）。

话说回来，做好这些事情都是需要代价的，也就是时间上的代价，更不用说还有学习成本了。想要马儿跑的快又不想让马儿吃草，那你是在白日做梦。XP 解决的问题不是如何更快地生产软件的问题，而是如果你有足够的时间，你会如何做好软件开发的问题。在严酷的时间限制下（国内大量存在着这样人有多大胆地有多大产的项目），这一切都将成为空谈。考虑到公司政治，你们公司有 3 个 PM，你是其中一个，他们做相同规模的项目只需要 2 个月时间，你说我现在采用 XP 和 TDD 能把这个项目做的更好（质量更高、客户更满意，云云），但是需要 3 个月的时间。如果你确定高层一定会首选 2 个月的方案，那么你提出这个建议岂不是要示弱于人？无聊的公司政治，除非你自己开的公司，谁能避的过？

确定基础需求，
快速建立简单模型，
小规模的Unit Test，
高效结对编成
XP开发速度是比较快的
而且把今天作的更简单一些也适合快速建立模型来进行进一步决策

单元测试能有开发(测试)人员来写，这的确要求太高了。

如果这能这样，我想项目成功的可能性会大大提高。
（成本问题暂不考虑）。

注意：红色为笔误，修改为蓝色。

主要测试人员的出发点和视角和开发人员是不一样的，他们更能够发现开发人员的一些错误和死角
测试驱动可以尝试一下:),极大提高质量

很多公司做项目时，跟本不会留给程序员时间去写单元测试

这个应该是问题的关键，国外的公司什么样没见过，不过国内的公司大部分
是没有预留这些时间的。

我个人觉得，既然是pair programming，那么两个人在分析设计阶段可以可以共同的来做，在确定好接口之后，就可以分工，一个写实际的功能，一个写单元测试代码。将单元测试的责任挪移到QA那里恐怕有些麻烦，QA有可能要参与分析设计了，感觉已经变成一个开发者的角色了。

“客户（公司顾问）提供测试数据，根据这些数据，我们对我们所写程序进行测试，同不过就不可能满足需求。就这么看，测试基本上能够反应出程序功能。”我对我老大如是说，老大让我干活去。

我们的ERP总共签了6份合约，客户只付了一次M,接下来都不付了，因为发现程序不能跑。

程序开发人员只是实现测试，单元测试自上而下，所以很多人在做，coder只是写，绿条出现就是OK


所以slovenboy是真正做测试的人

这种测试，在软件测试中占很小的比例。这是模拟真实环境的测试，一般的公司
（比如国内的小公司）很少作这种测试，通常的做法都是到客户现场调试。


估计你们的ERP是给人家开发的，不是去实施。

这个观点的证据是正确的，结论不完全正确。