design-patterns - 使白盒测试更容易的编程设计模式？

Question

我想知道是否有一些编程设计模式可以使程序更容易进行白盒测试。我不是在谈论单元测试，而是更高级别的测试，例如基于白盒的功能测试、系统测试或一些边界测试。

例如:

对于基于 GUI 的程序，我们可以保留一个隐藏开关来从文本文件而不是 GUI 中读取输入。

对于一些基于 HTTP 的 C/S 应用程序，提供一个参数以在包传输期间禁用 gzip 选项，从而更容易使用 Fiddler 更改 HTTP 包。

还有其他模式或原则吗？

Answer 1

我不知道我是否完全明白你的问题，但是:

想想你的测试策略

换句话说，你必须知道你在什么场景下测试什么(整个系统，只是这个模块/类/函数/什么等等)(当我给它无效输入时，当用户这样做然后那样，等)以及为什么该测试足够重要以供考虑(这是一种常见用途，它测试边界条件等)。

我认为 Wikipedia article on software testing 中的“测试方法”和“测试级别”部分可能会帮助您推理您想要什么样的测试。

测试仍然是代码

您应该使您的测试保持与您的应用程序代码相同的工程质量水平。在这方面，应用所有可以帮助您解决问题的模式，但仅此而已!

按原样使用构建

我个人认为，出于多种原因，仅为测试而创建 secret 戳洞是一个坏主意。仅举几个:

他们可能无法以微妙的方式可靠地再现假定的交互。 “测试快捷方式”可能不会像普通用户那样触发完全相同的事情。每次提交对代码和测试的更改时，您必须非常 100% 确定您正在绕过什么(及其影响)。

测试需要好的设计。如果测试某些东西让您感到痛苦，您是否考虑过质疑您的设计？测试某些东西只是以脚本的方式使用它。使用您的产品不应该是痛苦的。 (然而，测试的脚本在某些环境中可能会很痛苦。是的，我知道。)对于单元测试尤其如此。

总有一些不经意的程序员可能会认为将测试快捷方式转变为实际、合法、正常的用例是个好主意。这有一切都需要南下，特别是如果他假设那段代码和其他代码一样经过深思熟虑(通常不是这样)。