单元测试对您意味着什么？

Question

天儿真好，

我正与一群离岸开发人员合作，他们一直使用单位测试一词。

他们的质量保证文件讨论了编写单元测试，然后对系统进行单元测试。

这与我对单元测试的解释不符。

我习惯将单元测试作为测试或测试套件，用于练习单个类，通常是黑盒子。被测试的类可能要求实现包含其他类，但通常它是由单元测试执行的单个类。

然后你有系统功能测试，整合测试，验收测试等。

我想知道这对我来说有点迂腐吗？或者这是您在参考单元测试和单元测试时的想法？

编辑：Rob Wells。我需要澄清的是，从黑匣子的角度来看这种测试只是一个方面。当使用模拟对象来验证内部行为时，您实际上是从白盒的角度进行测试，因为您知道要在框内发生什么。

Answer 1

开发人员通常使用单元测试来测试代码的隔离部分。它们涵盖边界案例，错误案例和正常案例。它们旨在证明有限代码段的正确性。如果你的所有单元测试都通过了，那么你已经证明了你的孤立代码片段可以做他们应该做的事情。

当您进行集成测试时，您正在查看端到端案例，以查看已通过单元测试的所有段是否一起工作。功能测试检查代码是否满足指定的要求。验收测试由最终用户完成，以确定他们是否批准最终产品。

Answer 2

没有理由为什么单元测试不能跨越多个类，甚至子模块，只要测试只处理一个一致的业务操作。想想“calculateWage”，这是一种BO的方法，它使用不同的策略来计算一个人的工资。在我看来，这是一个单元测试。

Answer 3

我尝试实现单元测试以仅测试单个方法。并且我努力为我正在测试的方法使用的依赖类和方法创建“模拟”类... ...所以在该方法中执行代码实际上并不调用其他方法中的代码，单元测试不应该是“测试”（这些方法还有其他单元测试）这种方式，失败了单元测试可靠地表明单元测试正在测试的方法失败......

模拟类旨在“模拟”依赖类的接口和行为，以便我测试的方法可以调用它们，并且它们将根据系统要求以标准的，定义良好的方式运行。为了使这种方法起作用，必须在一个定义良好的接口上调用这些依赖类及其方法，以便“tester”进程可以将Mock版本的依赖类“注入”到被测试的类中实际生产版本......这有点像一种常见的设计模式，称为“依赖注入”或“控制反转”（IOC）

市场上有几种第三方工具可以帮助您实现这种模式。我听说过的是“Rhino-Mock”或类似的东西......

编辑：Rob Wells。 @Charles。谢谢你。我忘了使用模拟对象来完全替换使用除被测试者之外的其他类。

在提到模拟对象之后我记得的其他几件事是：

• 它们可用于模拟包含的类返回的错误。
• 它们可用于引发特定异常以检查被测试类中的异常处理。
• 它们可用于模拟设置成本高的项目，例如一个大的SQL DB后端。
• 它们可用于验证传入请求的内容。

有关更多信息，请查看Martin Fowler的论文“Mocks Aren't Stubs”和The Pragmatic Programmers的文章“Mock Objects”

Answer 4

我听说过首先完成许多单元测试的技术，并围绕它们进行开发。有人刚评论说这是“测试驱动开发”--TDD（谢谢Elie）。

但是，如果这是一项离岸业务，可能会因为他们花时间进行这些单元测试而向您收取更多资金 - 那么我会小心。从有经验的单元测试中获得第二意见，他们将验证他们实际上正如他们所说的那样做。

根据我的理解，单元测试会为任何开发项目增加更多时间，但当然可以提供一些质量控制。尽管如此，这是我想要的内部项目的质量控制类型。这可能只是离岸公司抛出的东西，给你一个温暖的模糊。

Answer 5

您用于测试的过程与用于支持它的技术之间存在差异。用于单元测试的各种框架通常非常灵活，可用于测试小型代码单元，大型单元甚至测试整个过程。这种灵活性可能导致混淆。

我的建议是，无论采用何种具体的方法或流程，您都要将各种单元测试分成不同的组件或模块。确切的安排取决于您的代码和公司的组织。

使用单元测试框架的累积效果是代码的大部分测试都是自动化的。正确采用开发人员可以通过完整的Q＆amp; A流程更好地评估代码代码的更改。至于Q＆amp;流程本身使得他们的时间更有效率，因为开发中的代码质量应该更高。

了解它不是所有质量问题的答案，它只是一个有用的工具，就像你使用的其他工具一样。

Answer 6

Wikipedia似乎表明单元测试是关于测试最小量的代码，这些代码在OO编程的情况下将成为类的一种方法。

有些人可能对单元测试的含义有更一般的含义，有些人可能认为某些集成测试是单元测试，其中单元是组件的混合。

Answer 7

http://en.wikipedia.org/wiki/Software_testing的传统视图是http://en.wikipedia.org/wiki/Software_engineering的一部分。但我喜欢敏捷单元测试的想法：测试是一个敏捷单元测试，如果它足够快，以便程序员总是运行它。

Answer 8

单元测试是您在完成工作的过程中可以获得的最小且唯一的信心。重要的是，反复建立一个防止回归和规范偏差的屏障，而不是如何将它实际集成到面向对象的体系结构中。

Answer 9

这几乎是“What is a 'Unit'?”问题的重复。

“单位”可以灵活定义。如果他们的文件没有“单位”的定义，你需要澄清这一点。

可能他们认为单位是一个重要的代码集合。这不是最理想的定义。

虽然我同意你有几层测试（单元，模块，包，应用程序），但我也认为可以通过单元测试工具完成大部分测试。导致“什么是单位？”问题一直存在。

单位取决于具体情况。对于单个开发人员，单位必须是Class。有时，它也意味着模块或包。

但对于团队而言，他们的单位可能是一个包裹或一个完整的申请。

Answer 10

我们的想法有什么关系？这里的问题是您对他们在文档中使用的术语不满意。你为什么不跟他们讨论呢？

Answer 11

十年前，在当前使用“单元测试”作为代码编写的测试之前，同样的名称适用于手动测试。我曾在一家软件开发公司工作，拥有非常正式的软件开发流程。在编写任何代码之前，我们必须编写“单元测试”。在那个时代，单元测试是用文本文档（例如Word）编写的。他们描述了用户在使用应用时要遵循的确切步骤。例如，他们描述了在页面上键入的确切输入以设置新客户。或者，用户要搜索特定产品，并看到显示的信息与测试文档匹配。因此，测试是测试人员遵循的脚本，他们也记录了结果。当单元测试的新版本出现时，一段时间试图弄清楚它们是否意味着旧的，人工测试或新的编码测试是令人困惑的。

Answer 12

我也带领一群离岸团队。假设我们有一套单元测试......但这并不意味着什么。 :)所以我们更多地依赖功能和测试人员的质量。单元测试的继承问题是你对功能有完全的了解，并且你相信开发人员。在现实世界中，这很难假设..