正如我从一些问答环节中了解到的（参见this 和this），单元测试应该由开发人员编写。
在我以前的工作场所，我们试图将这项任务交给 QA 工程师，但没有奏效。可能是因为它已经是一个项目的中间，他没有机会进行重要的代码覆盖，或者可能是因为其他原因。
你认为让开发人员免于以这种方式编写单元测试是个坏主意吗？
【问题讨论】：
标签： unit-testing qa
一般来说，我认为这是一个坏主意。单元测试指导开发人员编写模块化（因此是有用的、可重用的）代码，因为他们的代码需要与生产系统和测试代码一起使用。
【讨论】：
单元测试和 QA 测试的意图之间有一个微妙但重要的区别：QA 测试验证功能；单元测试验证设计。也就是说，产品的外观与产品的内部形成对比。
QA 人员不熟悉产品的内部设计，这是故意的，因为他们必须模仿用户的观点。另一方面，开发人员非常了解内部工作原理，并且对他们来说，验证设计的机制将是有意义的，如果有的话。
因此，开发人员而不是 QA 人员编写单元测试是绝对自然的。
【讨论】：
这取决于您计划如何实施测试工作流程。
不好：
开发人员编写他的代码，然后其他人尝试添加单元测试来测试此代码。这里的问题是开发人员不会关心编写易于测试的代码。可能会花费大量时间来尝试使单元测试适应可测试性差的代码，或者浪费时间重构原始代码以提高可测试性。
好：
开发人员以外的其他人编写单元测试，然后开发人员编写他的代码，试图让所有这些测试都变成绿色。起初这可能有点尴尬，因为必须存在一些基本接口才能实现测试，但基本接口应该在设计文档中定义，以便开发人员可以为测试开发人员准备接口。优点是，测试开发人员尝试编写尽可能多的独立于实际实现的测试，而原始开发人员将根据其代码的内部结构编写测试，而不是想象其他问题。否则，他会在他的实施中防范它们。
“好的”方法在我的两个项目中运行良好，但我们使用了一种非类型化语言 (Smalltalk)，我们只需要就类名达成一致即可运行测试。在 Java 中，您必须至少实现一个接口来调用函数。
【讨论】：
是的。
开发人员编写单元测试以确保“单元”执行它应该执行的操作。 QA 人员测试整个应用程序。
此外，单元测试就是代码，开发人员编写代码。大多数时候 QA 工程师不编写代码。
【讨论】：
开发人员必须编写单元测试。 否则就像开发人员不必关心质量一样。 此外，单元测试有助于开发人员编写更好的代码。
也许您听说过TDD？ “测试驱动开发”确实是一种很好的开发实践。它的主要目的是在编写实际代码之前开发单元测试（这很奇怪，当我们开始使用 TDD 时，我承认）......
【讨论】：
乍一看，团队中有一个专门负责单元测试的人似乎很有趣；因为他将审查所有代码。这也将减轻一名开发人员在生产代码和单元测试中犯同样错误的风险。
然而，为了进行单元测试，代码必须是可测试的；当它收到的代码无法测试时，他能做什么？重写吗？重构它？没有单元测试？
简而言之，我认为这不是一个好主意。
【讨论】：
在我工作的地方，我们都进行单元测试，但不是基于您自己的代码。您仍然会编写可测试的代码，并且仍将关注质量。开发人员对他们不从事的软件领域变得更加熟悉。每个人都知道代码库，并且可以从其他开发人员那里接手。
对于编写单元测试的非软件开发人员，我同意所有其他答案。这是个坏主意。
在您的问题中，您说您有一个人进行单元测试。良好的单元测试需要付出很多努力，具体取决于所需的测试覆盖率。它是开发团队工作量的 50% 到 100%。一个测试大量开发人员代码的人会完全不知所措。
【讨论】：
我不认为这会很糟糕，我只是不认为这是可能的。如果代码没有先写测试，它可能是不可测试的。
QA 人员是否正在重构代码以使其可测试？
如果是这样，那很好，我不在乎他们的头衔是什么。如果他们不是，那么我怀疑他们会成功。
【讨论】：
我认为编写单元测试对 QA 来说通常是不好的。单元测试是代码，它们与开发代码的构造方式密切相关。因此，开发人员最清楚哪些测试最有意义。
另一方面，我认为 QA 应该尽可能接近单元测试。 QA 需要与开发人员建立良好的关系，并尝试了解代码设计。为什么？当开发人员编写单元测试时，重点仍然是开发，而不是测试。你不能相信（不是坏意义上的）开发人员能提出最好的测试用例，并且她有很好的覆盖范围。由于 QA 专门从事测试，因此在单元测试期间让 QA 和开发人员尽可能接近可能是个好主意。
【讨论】：
开发人员或其他开发人员（代码审查员）应记录单元测试用例，这些用例应以开发的代码或技术设计为基础。但是，QA 测试用例应该由基于功能设计的功能测试人员编写。
这里的根本区别在于，UT 涵盖逻辑、内部流程、性能、优化，而 QA 涵盖模仿用户体验的功能流程。
【讨论】：