我不明白单元测试如何可能受益。 对于测试人员来说，测试整个输出整体而不是单元测试是不够的？
感谢。
答案 0 :(得分：8)
您所描述的是集成测试。当您的输出不再正确时，哪些集成测试无法告诉您，哪个大型应用程序无法正常工作。
单元测试的优势在于，您可以为需要程序执行的每个业务假设或算法步骤编写测试。当有人向您的应用程序添加或更改代码时，您会立即确切地知道在引入错误时哪个步骤，哪个步骤，甚至哪个代码行都被破坏了。仅仅因为这个原因而节省的时间使得它值得，但是有一个甚至更大的优势，因为无法引入回归错误（假设您的测试在构建软件时自动运行）。如果您修复了一个错误，然后专门编写一个测试来捕获该错误，那么任何人都不会意外地再次引入它。
集成测试和单元测试的结合可以让您在晚上更容易入睡，特别是当您在当天检查了大量代码时。
答案 1 :(得分：5)
越早捕获错误，它们就越便宜。编码器在单元测试过程中发现的一个错误非常便宜（只是修复了这个问题）。
在系统或集成测试期间发现的错误成本更高，因为您必须修复它并重新启动测试周期。
您的客户发现的错误将花费很多：重新编码，重新测试，重新包装等等。当你通知管理层在单元测试期间你没有抓住它时，它也可能会在你的derriere上留下痛苦的引导打印，因为你没有做任何事情，认为系统测试人员会发现所有问题： - ）
由于催化转换器无法正常工作，通用汽车召回10,000辆汽车需要多少钱？
现在想想如果他们发现这些转换器交付给他们之后会立即花多少钱，但之前将它们放入10,000辆汽车中。
我认为你会发现后一种选择要便宜一点。
这就是测试驱动开发和持续集成（有时）是一件好事的一个原因 - 测试一直在进行。
此外，单元测试不会检查程序是否作为一个整体工作，只是每个小位都按预期执行。这通常比批次更多，而不是更高级别的测试会检查。
答案 2 :(得分：5)
根据我的经验：
摘要：
答案 3 :(得分：2)
仍然需要执行一定级别的手动测试，但单元测试用于减少使其进入该阶段的缺陷数量。单元测试测试系统的最小部分，如果它们全部工作，整个应用程序的正常工作机会会大大增加。
它还可以在添加新功能时提供帮助，因为可以快速自动执行回归测试。
答案 4 :(得分：2)
对于足够复杂的应用程序，整体测试整个输出可能无法涵盖足够多的不同可能性。例如，任何给定的应用程序都有大量不同的代码路径，可以根据输入进行跟踪。在典型的测试中，代码的许多部分可能从未遇到过，因为它们仅在某些情况下使用，因此您无法确定在测试情况下未运行的任何代码实际上是否正常工作。此外，代码的一个部分中的错误可能会被其他代码段中的其他部分掩盖，因此您可能永远不会发现某些错误。
最好分别测试每个功能或类。这样，测试更容易编写，因为您只测试代码的某一小部分。在测试时也可以更容易地覆盖每个可能的代码路径，如果分别测试每个小部分，那么即使在应用程序中运行时代码的其他部分经常会掩盖这些错误，您也可以检测到错误。
答案 5 :(得分：2)
帮自己一个忙，先尝试单元测试。直到我意识到有用/强大的单元测试是多么有用之后，我才非常怀疑。如果您考虑一下，它们实际上并不适合添加到您的工作负载中。它们可以让您高枕无忧，并允许您继续扩展您的应用程序，同时确保您的代码是可靠的。您可以立即获得有关何时可能破坏某些内容的反馈，这是非常有价值的。
关于为什么要测试小部分代码的问题请考虑这一点：假设您的巨型应用程序使用您编写的酷XOR加密方案，并最终产品管理更改了生成这些加密字符串的要求。所以你说：“哎呀，我写了加密例程，所以我会继续进行改变。我需要15分钟，我们都会回家参加派对。”好吧，也许你在这个过程中引入了一个bug。可是等等！！！您方便的花花公子TestXOREncryption（）测试方法会立即告诉您预期的输出与输入不匹配。 Bingo，这就是为什么你提前将你的单元测试分解成小的“单位”进行测试的原因，因为在你的大型应用程序中，你几乎不会想到这一点。
此外，一旦你进入定期编写单元测试的思维框架，你就会意识到尽管你在开始时花费了前期成本，但是在开发周期中你会得到10倍的回报。当您可以快速识别代码中引入问题的区域时。
单元测试没有灵丹妙药，因为您识别问题的能力与您编写的测试一样好。它归结为提供更好的产品，减轻压力和头痛。 =）
答案 6 :(得分：2)
同意大多数答案。让我们深入探讨速度问题。以下是一些实数：
单元测试会导致 1或2分钟 新编译。作为真正的单元测试 （没有与外部的互动 他们可以覆盖一个像dbs这样的系统 很多逻辑真的很快。
自动功能测试会导致 1或2小时。它们运行在一个简化的平台上，但有时会覆盖多个系统和数据库 - 这真的会导致速度加快。
自动整合测试每天一次 结果这些都是全餐交易，但是如此沉重和缓慢，我们每天只能执行一次并且需要几个小时。
手动回归结果在几周之后出现。我们每天都会向测试人员提供几次测试，但是你的变化最好不会在一两年内实际回归。
我想知道我在1分钟或2分钟内发生的事情，而不是几周，甚至几个小时。这就是人们谈论的单元测试的10倍投资回报率。
答案 7 :(得分：1)
这是一个难以接近的问题，因为它质疑了如此巨大的广度。这是我的简短回答：
测试驱动开发（或TDD）试图证明应用程序（或代码块）的每个逻辑单元完全按照它应该的方式运行。为了生产效率，尽可能使测试尽可能自动化，这怎么可能真的有害？
通过测试每一段逻辑代码，您可以信任某些层次结构中代码的使用。假设我构建了一个依赖于线程安全堆栈实现的应用程序。在构建之前，堆栈是否应该保证在每个阶段都能正常工作？
关键是，如果整个应用程序中的某些内容中断，这意味着仅查看总输出/结果，您如何知道它的来源？好吧，调试，当然！这让你回到起步的地方。 TDD允许您 - 在开发过程中绕过这个最痛苦的阶段。
答案 8 :(得分：1)
测试人员通常会测试端到端的功能。显然，这适用于用户场景并具有令人难以置信的价值。
单元测试提供不同的功能。开发人员在没有其他功能或与其他功能组合的情况下验证他们编写的组件是否正常工作的方法。这提供了一系列的价值，包括
答案 9 :(得分：1)
一个开始的地方是回归测试。一旦发现错误，请编写一个小测试来演示错误，修复它，然后确保测试现在通过。将来，您可以在每次发布之前运行该测试，以确保未重新引入该错误。
为什么在单元级别而不是整个程序级别？速度。在良好的代码中，隔离一个小单元并编写一个小测试要比将一个复杂的程序驱动到bug点要快得多。然后，当测试单元测试通常比集成测试运行得快得多。
答案 10 :(得分：0)
非常简单：单元测试更容易编写，因为您只测试单个方法的功能。并且错误更容易修复，因为您确切知道哪种方法被破坏了。
但正如其他回答者所指出的那样，单元测试不是最终测试的全部。它们只是等式中最小的一部分。
答案 11 :(得分：0)
软件最大的困难可能就是交互事物的数量之多，最有用的技术是减少必须考虑的事情。
例如，使用更高级别的语言而不是更低级别的语言可以提高工作效率，因为一行是单独的，并且能够用更少的行编写程序会减少事物的数量。
程序编程是通过将函数视为事物来降低复杂性的尝试。但是，为了做到这一点，我们必须能够以连贯的方式思考这个功能的作用，并确信我们是对的。 （面向对象的编程在更大范围内做了类似的事情。）
有几种方法可以做到这一点。按合同设计是一种准确指定函数功能的方法。使用函数参数而不是全局变量来调用函数并获得结果会降低函数的复杂性。
单元测试是验证函数是否符合预期功能的一种方法。通常可以测试函数中的所有代码，有时还可以测试所有执行路径。这是一种判断函数是否正常工作的方法。如果该功能有效，我们可以将其视为一件事，而不是我们必须跟踪的多件事。
它用于其他目的。单元测试通常可以快速运行，因此当它们易于修复时，可以快速捕获错误。如果开发人员确保函数在签入之前通过了测试，那么测试就是记录函数保证正确性的一种形式。创建测试的行为迫使测试编写者思考函数应该做什么。在那之后，谁想要改变可以查看测试，看看他或她是否被正确理解。
相比之下，较大的测试并非详尽无遗，因此很容易错过很多错误。他们不善于本地化bug。它们通常以相当长的间隔执行，因此它们可能会在错误发生后的某个时间检测到它。它们定义了总体用户体验的一部分，但没有为推理系统的任何部分提供依据。它们不应该被忽视，但它们不能代替单元测试。
答案 12 :(得分：0)
正如其他人所说，反馈循环的长度和问题与特定组件的隔离是单元测试的关键优势。
它们与功能测试互补的另一种方式是如何在一些组织中跟踪覆盖范围：
功能测试可能会错过已实现但未在规范中的功能。
基于代码，单元测试可能会错过某个功能未实现，这是功能测试的基于需求的覆盖分析的来源。
最后一点：有些事情在单位级别更容易/更快地进行测试，尤其是在错误情况下。
答案 13 :(得分：0)
单元测试可以帮助您更清楚地识别错误的来源，并让您知道您之前遇到问题。两者都很好，但它们不同，单元测试确实有好处。
答案 14 :(得分：0)
您测试的软件是一个系统。当您作为一个整体进行测试时，您将进行黑盒测试，因为您主要处理输入和输出。当你无法进入系统时，Black box testing很棒。
但是，由于您经常这样做，因此您创建了许多单元测试，实际上将您的系统测试为白盒。您可以通过多种方式对系统进行切片，并根据系统内部结构组织测试。 White box testing为您提供了更多测试和分析系统的方法。它显然是对黑盒测试的补充，不应被视为替代或竞争方法。