TDD 与防御性编程

Question

鲍伯叔叔说:

“非公共(public) API 中的防御性编程是不做 TDD 的团队的一种气味和症状。”

我想知道 TDD 如何避免以意外方式使用(内部)函数？我认为TDD无法避免。它仅表明该函数被正确使用，因为调用函数被它通过的单元测试所覆盖。

当使用(非防御性)功能开发新功能时，此功能也使用 TDD 开发。因此，意外使用该功能将使新功能测试失败。

因此，使用 TDD 驱动新功能将迫使您正确使用(内部)功能。

你认为这就是鲍勃叔叔的推文的意思吗？

Answer 1

So using TDD to drive new features will force you to correctly use (internal) functions.

确切地。但是请记住这里的细微“差距”:您应该使用 TDD 编写(单元)测试来测试 契约(Contract) 您的 公众 方法。你不关心这些方法的实现——那是所有内部实现细节。

因此:如果您的"new"代码以非预期方式使用现有方法，您会被“告知”，因为抛出异常或收到意外结果。

这就是我所说的“差距”:你看，上面描述了一种黑盒测试方法。你有一个公共(public)方法 X，并且你验证了它的公共(public)合约。将其与白盒测试进行比较，在白盒测试中，您编写测试以涵盖 X 中采用的所有路径。这样做时，您可能会注意到:“可以在我的内部方法中测试一个条件，我必须驱动这个特殊数据”。

但正如所说 - 我认为你应该进行黑盒测试 - 在重构内部方法时，白盒测试可能很容易破坏。

这里还有一个额外的维度:请记住，理想情况下，您 更改代码以实现新功能。这意味着 添加 新特性只能通过编写新的类和方法来实现。这意味着您的新代码没有机会使用私有(private)内部方法。因为你在一个新类(class)。换句话说:当您经常碰巧遇到内部方法以多种不同方式使用的情况时-那么您可能正在做某事 错了 .

理想的路径是:通过创建一组新类来实现新需求。稍后，您必须通过编写更多类来添加其他要求。

在那条理想的道路上——没有 需要用于内部方法中的防御性编程。因为您完全了解此类内部方法的每个用例!

因此，结论是:避免在内部方法中进行防御性编程。确保您的公共(public) API 检查所有先决条件，以便在出现问题时(尽可能快地)失败。尽量避免这些内部一致性检查——因为它们往往会使你的代码膨胀——并请放心:在 5 周或 5 个月内，你将不会记得你是否真的需要该检查，或者它是否只是“防御性的”。