security - TDD 能否成为过度杀伤数据验证的有效替代方案？

Question

考虑这两个数据验证场景:

到处检查一切

确保采用一个或多个参数的每个方法都实际检查它们以确保它们在语法上有效。

优点

• 非常精细的检查粒度。
• 如果正在编写的代码是为某种类型的库编写的，我们确保限制在使用它的开发人员未能提供有效数据时可能造成的损害。

缺点

• 总是执行大部分时间不需要的检查成本很高。
• 仍然有可能时常忘记添加支票。
• 正在编写更多代码，因此需要维护。

利用 TDD 的优势

仅当数据从外部世界输入您的代码时才验证数据。为确保内部数据在语法上始终正确，请创建测试以检查每个返回值的方法。以确保如果有效数据进入，则有效数据退出。

优点和缺点实际上与前一种方法的优点和缺点相反。

截至目前，我使用的是第一种方法，但由于我采用的是测试驱动开发，我认为也许我可以使用第二种方法。

优点很明显，不过，我想知道它是否像第一种方法一样安全。

Answer 1

听起来第一种方法是契约驱动的，其中一个方面是您还需要验证从任何公共(public)接口(interface)返回的内容是否符合契约。

但是，我认为这两种方法都是有效的，但有很大不同。

TDD 只部分处理公共(public)接口(interface)，因为它应该检查每个输入是否得到正确验证，不幸的是，除非你在单独的函数中进行所有验证，否则要进行充分测试，很难确保这个函数正在正确测试 3 或 4 个参数的有效性。无论采用哪种方法，您必须编写的测试数量都非常多。

如果您使用的是库，那么在每个可以从外部直接调用的函数中(外部是库外部)，那么您将需要检查每个输入是否有效，并且根据契约(Contract)，返回 null 或抛出异常。但是，它必须与文档一致。

一旦你验证了它，就没有理由强制验证私有(private)函数，因为它们只能从库中调用，你应该验证你只处理有效数据。

不幸的是，不管怎样，都需要进行大量测试。所有这些测试都是为了确保您不会遇到任何意外问题，但这通常有助于证明编写和维护它们的成本是合理的。

关于你的问题，如果你的测试真的写得很好，并且你确保所有的有效性检查都完全完成，那么它应该是安全的，但风险是如果你认为它是安全的并且你写得不好测试那么它实际上比没有测试更糟糕，因为假设您的测试编写得很好。

我会同时使用这两种方法，直到您知道您的测试编写得很好，然后才使用 TDD。