天，
我正在与一群离岸开发人员一起工作，他们一直在非常松散地使用术语单元测试。
他们的 QA 文档讨论了编写单元测试然后执行系统的单元测试。
这根本不符合我对单元测试的解释。
我习惯于将单元测试作为一个测试或一组测试，用于练习单个类，通常作为一个黑盒。被测类可能需要实现包含其他类，但通常它是由单元测试执行的单个类。
然后是系统功能测试、集成测试、验收测试等。
我想知道这对我来说是不是有点迂腐？或者这就是您在提到单元测试和单元测试时所想到的？
编辑：罗布·威尔斯。我需要澄清的是，从黑盒的角度进行此类测试只是一方面。当使用模拟对象来验证内部行为时，您实际上是从白盒的角度进行测试，因为您知道要在盒子内发生什么。
开发人员通常使用单元测试来测试独立的代码段。它们涵盖边界情况、错误情况和正常情况。它们旨在证明有限代码段的正确性。如果你所有的单元测试都通过了，那么你已经证明你的独立代码段做了它们应该做的事情。
当您进行集成测试时，您正在查看端到端案例，以查看所有通过单元测试的段是否一起工作。功能测试检查代码是否满足指定的要求。验收测试由最终用户完成，以查看他们是否批准最终产品。
没有理由单元测试不能跨越多个类，甚至子模块，只要测试只处理一个一致的业务操作。想想“calculateWage”，BO 的一种方法，它使用不同的策略来计算一个人的薪水。在我看来，这是一个单元测试。
我尝试实施单元测试来只测试一个方法。我努力为我正在测试的方法所使用的依赖类和方法创建“模拟”类......以便在该方法中执行代码实际上不会调用单元中其他方法中的代码测试不应该是“测试”（这些方法还有其他单元测试）这样，单元测试的失败可靠地表明单元测试正在测试的方法失败......
模拟类旨在“模拟”依赖类的接口和行为，以便我正在测试的方法可以调用它们，并且它们将根据系统要求以标准、明确定义的方式运行。为了使这种方法有效，对此类依赖类及其方法的调用必须在定义良好的接口上进行，以便“测试器”进程可以将依赖类的 Mock 版本“注入”到正在测试的类中的实际生产版本...... 这有点像一种常见的设计模式，称为“依赖注入”或“控制反转”（IOC）
市场上有几种第三方工具可以帮助您实现这种模式。我听说过一种叫做“Rhino-Mock”或类似的东西......
编辑：罗布·威尔斯。@查尔斯。谢谢你。我忘记了使用模拟对象来完全替换使用除了被测对象之外的其他类。
在您提到模拟对象后，我还记得的其他几件事是：
有关更多信息，请查看 Martin Fowler 的论文“ Mocks Aren't Stubs ”和 The Pragmatic Programmers 的文章“ Mock Objects ”
我听说过许多单元测试首先完成的技术，然后围绕它们进行开发。刚刚有人评论说这是“测试驱动开发”——TDD（感谢 Elie）。
但是，如果这是一个离岸业务，可能会因为他们花时间进行这些单元测试而向您收取更多费用 - 那么我会小心。从具有单元测试经验的人那里获得第二意见，他们将验证他们实际上正在按照他们所说的那样做。
据我了解，单元测试将为任何开发项目增加一点时间，但当然可以提供一些质量控制。尽管如此，这是我想要的内部项目的质量控制类型。这可能只是离岸公司扔在那里给你一个温暖的模糊的东西。
您用于测试的过程与用于支持它的技术之间存在差异。用于单元测试的各种框架通常都非常灵活，可以用于测试小代码单元、大单元甚至整个流程。这种灵活性会导致混乱。
我的建议是，无论您采用何种特定方法或流程，都将各种单元测试分成不同的程序集或模块。确切的安排取决于您的代码和您公司的组织。
使用单元测试框架的累积效应是代码的大部分测试都是自动化的。正确采用的开发人员可以更好地评估对代码的更改，而无需经过完整的问答过程。至于问答流程本身，它使他们的时间更有效率，因为开发出来的代码质量应该更高。
理解它不是所有质量问题的答案，它只是一个有用的工具，就像您使用的其他工具一样。
维基百科似乎暗示单元测试是关于测试最少量的代码，在面向对象编程的情况下，这将是类上的一种方法。
有些人可能对单元测试的含义有更笼统的术语，有些人可能认为某些集成测试是单元测试，其中单元是组件的混合。
传统观点认为http://en.wikipedia.org/wiki/Software_testing是http://en.wikipedia.org/wiki/Software_engineering的一部分。但我喜欢敏捷单元测试的想法：如果测试足够快，程序员总是运行它，那么它就是敏捷单元测试。
单元测试是你可以让自己在完成的路上最小的也是唯一的信心。这才是重要的，迭代地构建一个防止回归和规范偏差的屏障，而不是你如何将它实际集成到你的面向对象架构中。
这几乎是“什么是‘单位’？ ”问题的重复。
“单位”可以灵活定义。如果他们的文档没有“单位”的定义，您需要澄清这一点。
可能是他们将单元视为一大堆代码。这不是最理想的定义。
虽然我同意您有几层测试（单元、模块、包、应用程序），但我也认为其中大部分可以使用单元测试工具来完成。导致“什么是单位？” 问题一直在出现。
单位取决于上下文。对于个人开发者，单位必须是类。有时，它也意味着模块或包。
然而，对于一个团队来说，他们的单元可能是一个包或一个完整的应用程序。
我们怎么想有什么关系？这里的问题是您对他们在文档中使用的术语不满意。你为什么不和他们讨论呢？
十年前，在当前使用“单元测试”作为用代码编写的测试之前，同样的名称被应用于手动测试。我在一家软件开发公司工作，软件开发过程非常正式。在编写任何代码之前，我们必须编写“单元测试”。在那个时代，单元测试是在文本文档中编写的（例如 Word）。他们描述了用户在使用该应用程序时要遵循的确切步骤。例如，他们描述了在页面上键入以设置新客户的确切输入。或者，用户要搜索特定产品，并查看显示的信息与测试文档匹配。因此，测试是测试人员遵循的脚本，他们还记录了结果。当单元测试的新化身出现时，
我也带领着一群离岸团队。假设我们有一组单元测试......但这并不意味着什么。:) 所以我们更多地依赖功能和测试人员的质量。单元测试的继承问题是您对函数有完美的了解，并且您信任开发人员。在现实世界中，这很难假设..