TDD是否会使防御性编程变得多余？

#1 楼

这是荒谬的。 TDD强制代码通过测试，并强制所有代码对其进行一些测试。它不会阻止您的使用者错误地调用代码，也不会神奇地防止程序员丢失测试用例。

没有一种方法可以强迫用户正确使用代码。

有一点要说的是，如果您完美地完成了TDD，您将在实现之前在一个测试用例中捕获了大于0的检查，并通过添加检查来解决了这个问题。但是，如果您执行了TDD，则您的要求（在构造函数中> 0）将首先显示为失败的测试用例。因此，在添加支票后给您提供测试。

测试某些防御条件也是合理的（您添加了逻辑，为什么不想要测试那么容易测试的东西？）。我不确定为什么您似乎不同意这种说法。


还是这两种技术相辅相成？


TDD将发展测试。实现参数验证将使它们通过。

#2 楼

防御性编程和单元测试是两种捕获错误的不同方法，每种方法都有不同的优势。仅使用一种检测错误的方法会使您的错误检测机制变得脆弱。同时使用这两种方法，即使在不是面向公众的API的代码中，也可能捕获彼此可能遗漏的错误；例如，有人可能忘记为传递到公共API中的无效数据添加单元测试。在适当的地方检查所有内容意味着有更多机会抓住该错误。

在信息安全中，这称为深度防御。进行多层防御可以确保如果其中一项失败，那么还有其他方面可以阻止。

您的同事对一件事是正确的：您应该测试您的验证，但这不是“不必要的工作”。它与测试任何其他代码相同，您要确保所有用法，即使无效的用法也都有预期的结果。

#3 楼

TDD绝对不能取代防御性编程。相反，您可以使用TDD来确保所有防御措施都到位并且可以按预期工作。

在TDD中，您不应该先编写测试就不要编写代码-遵循红绿重构虔诚地骑自行车。这意味着，如果要添加验证，请首先编写一个需要此验证的测试。用负数和零调用有问题的方法，并期望它引发异常。

此外，请不要忘记“重构”步骤。尽管TDD是测试驱动的，但这并不意味着仅测试。您仍然应该应用适当的设计，并编写明智的代码。编写防御性代码是明智的代码，因为它使期望更明确，代码整体更健壮-尽早发现可能的错误使它们更易于调试。

但是我们不应该使用测试来定位错误？断言和测试是互补的。一个好的测试策略将混合使用各种方法来确保软件的健壮性。只有单元测试或集成测试或代码中的声明都不能令人满意，您需要一个良好的组合来以可接受的努力使您的软件具有足够的信心。

那么，对同事的概念上的误解：单元测试永远不能测试类的使用，只是单元本身可以按预期工作。您将使用集成测试来检查各个组件之间的交互是否起作用，但是可能的测试用例的组合爆炸使得无法测试所有内容。因此，集成测试应将自己限制在几个重要的案例中。涵盖边缘情况和错误情况的更详细的测试更适合单元测试。

#4 楼

可以通过测试来支持并确保防御性编程。
防御性编程可以在运行时保护系统的完整性。
测试是（主要是静态的）诊断工具。在运行时，您的测试遥遥无期。它们就像用来搭建高砖墙或岩石圆顶的脚手架。您不会在结构中留下重要的部分，因为在施工过程中有脚手架将其支撑起来。在构建过程中，您有一个脚手架将其支撑起来，以便于将所有重要的部分放入其中。
编辑：类比
与代码中的注释类比怎么样？
注释有其目的，但是可以多余甚至有害。例如，如果您将有关代码的内在知识放入注释中，然后更改代码，则注释最好变得无关紧要，最坏的情况下变得有害。
因此，您将代码库的许多内在知识放入了注释中。测试，例如MethodA不能为null，MethodB的参数必须为> 0。然后代码更改。现在对于A来说可以为Null，而B可以取小到-10的值。现在，现有测试在功能上是错误的，但仍会继续通过。
是的，您应该在更新代码的同时更新测试。您还应该在更新代码的同时更新（或删除）注释。但是我们都知道这些事情并不总是会发生，并且会出错。
测试可以验证系统的行为。实际行为是系统本身固有的，而不是测试固有的。
可能会出错的原因是什么？
关于测试的目标是思考所有可能出错的地方，编写一个测试为此，它会检查正确的行为，然后编写运行时代码，使其通过所有测试。
这意味着防御性编程才是关键。
如果测试很全面，TDD会驱动防御性编程。
更多测试，推动更多防御性编程
当不可避免地发现错误时，将编写更多测试以对表现该错误的条件进行建模。然后固定代码，使这些测试通过，然后将新测试保留在测试套件中。
一套好的测试将把好的和坏的参数同时传递给函数/方法，并期望一致的结果。反过来，这意味着被测试的组件将使用前提条件检查（防御性编程）来确认传递给它的参数。
一般来讲...
例如，如果特定对象的参数为null过程无效，那么至少一个测试将通过null，并且将期望某种“无效的null参数”异常/错误。
至少另一个测试将通过有效参数当然，-或遍历一个大数组并传递多个有效参数-并确认结果状态是否适当。
如果测试未通过该空参数并遭到期望的异常处理（并且之所以抛出该异常，是因为代码防御性地检查了传递给它的状态），那么null可能最终被分配给一个类的属性，或者被埋在不应包含的某种类型的集合中。
在类实例传递到的系统的某些完全不同的部分中导致意外行为，我软件出厂后，在某些遥远的地理位置。那是我们实际上要避免的事情，对吧？
甚至可能更糟。具有无效状态的类实例可以被序列化和存储，仅当重新构造供以后使用时才导致失败。 Geez，我不知道，也许它是某种机械控制系统，在关机后无法重启，因为它无法反序列化其自身的持久配置状态。或者可以将类实例序列化并传递给其他实体创建的完全不同的系统，该系统可能会崩溃。
尤其是如果其他系统的程序员没有防御性的代码。

#5 楼

我们一般不使用TDD来讨论“软件测试”，一般来说不使用“防御性编程”，而要谈论我最喜欢的进行防御性编程的方法，即使用断言。


因此，既然我们进行软件测试，就应该放弃在生产代码中放置断言语句，对吗？让我计算一下这种错误的方式：


断言是可选的，因此，如果您不喜欢它们，则只需禁用断言即可运行系统。测试不能（也不应）的事情。因为测试应该具有系统的黑盒视图，而断言却具有系统的白盒视图。 （当然，因为他们生活在其中。）
断言是出色的文档工具。没有评论曾经或将永远不会像断言同一件事的一段代码那样明确。而且，随着代码的发展，文档趋于过时，并且编译器无法以任何方式强制执行。
断言可以捕获测试代码中的错误。您是否曾经遇到过测试失败的情况，并且您不知道谁错了？生产代码还是测试？
断言比测试更有意义。测试将检查功能需求中规定的内容，但是代码通常必须做出某些假设，而这些假设要比技术上要远得多。编写功能需求文档的人很少想到除以零。
断言指出了只能广泛暗示测试的错误。因此，您的测试设置了一些广泛的前提条件，调用了一些冗长的代码，收集了结果，发现结果与预期不符。如果有足够的故障排除方法，您最终将确切找到问题出在哪里，但是断言通常会首先找到它。
断言可降低程序复杂度。您编写的每一行代码都会增加程序的复杂性。断言和final（readonly）关键字是我所知道的仅有的两种可真正降低程序复杂性的结构。这是无价的。
断言可以帮助编译器更好地理解您的代码。请在家尝试一下：void foo( Object x ) { assert x != null; if( x == null ) { } }您的编译器应发出警告，告诉您条件x == null始终为false。这可能非常有用。

以上是我的博客2014-09-21“断言和测试”中的帖子的摘要。

#6 楼

我相信大多数答案都缺少一个关键的区别：这取决于您的代码将如何使用。

有问题的模块是否将由其他客户端使用，而与正在测试的应用程序无关？如果要提供供第三方使用的库或API，则无法确保它们仅使用有效输入来调用代码。您必须验证所有输入。

但是，如果所讨论的模块仅由您控制的代码使用，那么您的朋友可能会有一点建议。您可以使用单元测试来验证是否仅使用有效输入调用了该模块。前提条件检查仍然可以被认为是一种很好的做法，但这是一个折衷方案：我向您散布了检查您永远不会出现的条件的代码，这只是掩盖了代码的意图。

我不同意前提条件检查需要更多的单元测试。如果您决定不需要测试某些形式的无效输入，则该函数是否包含前提条件检查都没有关系。记住测试应该验证行为，而不是实现细节。

#7 楼

这种论点让我感到困惑，因为当我开始练习TDD时，我的形式为“对象在时响应<确定方式>”的单元测试增加了2或3倍。我想知道您的同事如何在不进行功能验证的情况下成功通过此类单元测试。相反的情况是，单元测试表明您从未产生过差的输出，无法传递给其他函数的论点则很难证明。与第一种情况一样，它在很大程度上取决于对边缘情况的彻底覆盖，但是您还具有其他要求，即所有功能输入必须来自您已经对其单元进行测试的其他功能的输出，而不是来自用户输入或第三方模块。

换句话说，TDD的作用并不能阻止您需要验证代码，而不能帮助您避免忘记验证代码。

#8 楼

我认为我对您同事的言论的解释与大多数其他答案不同。

在我看来，论点是：


我们所有的代码经过单元测试。
使用您组件的所有代码都是我们的代码，或者如果没有经过其他人的单元测试（未明确说明，但这是我从“单元测试应捕获该类的任何不正确使用的理解”中了解的信息“）。
因此，对于您的函数的每个调用者，在某个地方可以模拟您的组件的单元测试，如果调用者将无效值传递给该模拟，则测试将失败。
因此，它不会不管您的函数在传递无效值时会做什么，因为我们的测试表明这不可能发生。

对我来说，此参数具有一定的逻辑性，但是过分依赖于单元测试来涵盖所有可能的情况。一个简单的事实是，100％的行/分支/路径覆盖率并不一定行使呼叫者可能传递的所有值，而100％覆盖呼叫者的所有可能状态（也就是说，其输入的所有可能值）和变量）在计算上是不可行的。

因此，我倾向于宁愿对调用方进行单元测试，以确保（就测试而言）它们永远不会传递错误的值，并且另外要求当传入错误值时，您的组件会以某种可识别的方式发生故障（至少在可能的范围内以您选择的语言识别错误值）。这将有助于在集成测试中出现问题时进行调试，并且同样可以帮助您的类中任何不那么严格地将其代码单元与该依赖性隔离的用户。

不过请注意，如果在传递值<= 0时记录并测试函数的行为，则负值将不再无效（至少，无效不超过throw的任何自变量，因为也被记录为引发异常！）。呼叫者有权依靠这种防御行为。在语言允许的情况下，这可能是最好的情况-该函数没有“无效输入”，但是希望不引起该函数引发异常的调用者应进行充分的单元测试，以确保它们不会

尽管认为您的同事比大多数回答都没有那么彻底错，但我得出的结论是相同的，那就是两种技术是相辅相成的。进行防御性编程，记录防御性检查并进行测试。如果您的代码用户在犯错误时无法从有用的错误消息中受益，则这项工作只是“不必要的”。从理论上讲，如果他们在将所有代码与您的代码集成之前对其进行了全面的单元测试，并且他们的测试中永远没有任何错误，那么他们将永远不会看到错误消息。实际上，即使他们正在进行TDD和完全依赖注入，他们仍然可能在开发过程中进行探索，或者测试可能会失效。结果是他们在代码完美之前就调用了您的代码！

#9 楼

公共接口可以并且将被滥用

对于任何非私有接口，您的同事“单元测试应该捕获类的任何不正确使用”的主张完全是错误的。如果可以使用整数参数来调用公共函数，则可以并且将使用任何整数参数来调用该公共函数，并且代码应具有适当的行为。如果公共功能签名接受例如Java Double类型，然后为null，NaN，MAX_VALUE和-Inf都是可能的值。您的单元测试无法捕获对该类的不正确使用，因为这些测试无法测试将使用该类的代码，因为该代码尚未编写，您可能未编写并且肯定超出了单元测试的范围。

另一方面，这种方法可能对（希望有更多的）私有属性有效-如果一个类可以确保某些事实始终为真（例如，属性X永远不能为null，整数位置不超过最大长度，当调用函数A时，所有必要的数据结构均已正确形成），因此可以适当地避免由于性能原因而一次又一次地验证这一点，而是依赖于单元测试。 />

#10 楼

防止滥用是一项功能，是由于对它的要求而开发的。 （并非所有接口都需要对滥用进行严格检查；例如，使用范围很窄的内部接口。）

该功能需要进行测试：针对滥用的防御措施是否有效？测试此功能的目的是试图证明它没有：误以为模块的某些误用并未被其检查发现。

如果需要特定检查，断言某些测试的存在使其不必要是不明智的。如果某个函数的某个功能（例如）在参数3为负数时抛出异常，则这是不可协商的。

但是，我怀疑您的同事实际上从某种意义上说是有意义的，在这种情况下，不需要对输入进行特定检查，对不良输入进行特定响应：在这种情况下，仅对鲁棒性有一个一般的了解。

检查进入某些顶级功能的部分原因是，可以保护某些弱的或未经过良好测试的内部代码免受意外组合的影响。参数（这样，如果对代码进行了良好的测试，则不需要进行检查：代码可以“克服”不良的参数）。

同事的想法中有真理，他可能意味着就是这样：如果我们用非常健壮的低级代码构建功能，这些低级别代码经过防御性编码并针对所有滥用情况进行了单独测试，那么高级功能可能很健壮，而无需进行自己的广泛自检。 />
如果违反了合同，它将翻译为som滥用低级功能，可能会引发异常或其他任何错误。

唯一的问题是，较低级别的异常不是特定于较高级别的接口的。这是否有问题取决于要求。如果要求仅仅是“该函数应具有较强的鲁棒性，以防止滥用，并抛出某种异常而不是崩溃，或者继续使用垃圾数据进行计算”，那么实际上，该函数可能会被其下层组件的所有鲁棒性所覆盖。

如果该功能需要与参数有关的非常具体，详细的错误报告，则较低级别的检查不能完全满足这些要求。它们仅确保函数以某种方式崩溃（不会继续使用错误的参数组合，从而产生垃圾结果）。如果编写客户端代码来专门捕获某些错误并进行处理，则可能无法正常工作。客户端代码本身可能正在获取参数所基于的数据作为输入，并且可能期望函数检查这些参数并将错误值转换为记录的特定错误（以便它可以处理这些错误）。错误），而不是其他一些无法处理的错误，甚至可能会停止软件映像。

TL; DR：您的同事可能不是白痴。你们只是围绕同一件事以不同的观点彼此交谈，因为这些要求没有被完全确定，而且每个人对什么是“未成文的要求”都有不同的想法。您认为，当对参数检查没有特定要求时，无论如何应该编写详细的检查代码；同事认为，只要参数错误，就让强大的低级代码崩溃。通过代码争论未成文的需求在某种程度上是徒劳的：认识到您不同意需求而不是代码。您的编码方式反映了您认为的要求；同事的方式代表了他对需求的看法。如果您以这种方式看待，那么很明显，代码本身并不包含对与错。该代码只是您对规范的看法的代理。

#11 楼

测试定义了您的班级契约。

作为必然的结果，没有测试定义了包含未定义行为的契约。因此，当您将null传递给Foo::Frobnicate(Widget widget)，并且发生了难以置信的运行时破坏时，您仍在您的课程中。

您以后决定，“我们不希望出现不确定的行为” ，这是一个明智的选择。这意味着您必须具有将null传递给Foo::Frobnicate(Widget widget)的预期行为。

并且您通过包含一个

[Test]
void Foo_FrobnicatesANullWidget_ThrowsInvalidArgument() 
{
    Given(Foo foo);
    When(foo.Frobnicate(null));
    Then(Expect_Exception(InvalidArgument));
}

来记录该决定。

#12 楼

一组良好的测试将练习您类的外部接口，并确保此类滥用会产生正确的响应（异常，或您定义为“正确”的任何内容）。实际上，我为类编写的第一个测试用例是使用超出范围的参数来调用其构造函数。

这种防御性编程通常会通过完全单元测试来消除

我有时采用的一个有用的想法是提供一种测试对象的不变量的方法。您的拆卸方法可以调用它来验证您对对象的外部操作不会破坏不变性。

#13 楼

TDD的测试将在代码开发过程中捕获错误。

作为防御性编程的一部分描述的边界检查将在代码使用过程中捕获错误。

如果两个域相同，即您正在编写的代码仅由该特定项目在内部使用，则TDD可能确实会排除您描述的防御性编程界限的必要性，但前提是这些类型在TDD测试中专门执行边界检查。


作为一个特定示例，假设使用TDD开发了财务代码库。其中一项测试可能断言特定值永远不会为负。这样可以确保库的开发人员在实现功能时不会意外滥用这些类。

但是，在库发布并在我自己的程序中使用它之后，那些TDD测试就不会不能阻止我分配一个负值（假设它是暴露的）。边界检查会。

我的观点是，如果仅在内部将代码用作较大应用程序开发的一部分（在TDD下），则TDD断言可以解决负值问题，将成为没有TDD框架和测试，界限检查事项的其他程序员使用的库。

#14 楼

TDD和防御性编程并驾齐驱。两者并没有多余，但实际上是互补的。当您拥有一个函数时，您要确保该函数能够按说明的方式工作并为其编写测试；如果您没有涵盖在输入错误，返回错误，状态错误等情况下会发生的情况，则说明您编写的测试不够鲁棒，即使所有测试都通过了，代码也很脆弱。

作为一名嵌入式工程师，我喜欢使用编写函数的示例来简单地将两个字节加在一起并返回结果，如下所示：

br />现在，如果您只是简单地执行*(sum) = a + b就可以了，但只需要一些输入即可。 a = 1和b = 2将成为sum = 3;但是，由于sum的大小为一个字节，因此a = 100和b = 200将由于溢出而产生sum = 44。在C语言中，在这种情况下，您将返回错误以表明函数已失败；在代码中抛出异常是相同的。不考虑失败或测试如何处理它们将无法长期运行，因为如果发生这些情况，将无法对其进行处理，并可能导致许多问题。