是应该测试内部实施还是仅测试公共行为？

Question

给定软件在哪里...

该系统由几个子系统组成

每个子系统都包含一些组件

每个组件都使用许多类来实现

...我喜欢为每个子系统或组件编写自动化测试。

我没有为组件的每个内部类编写测试（除非每个类都有助于组件的公共功能，因此可以通过组件的公共API从外部进行测试/测试）。

当我重构组件的实现时（作为添加新功能的一部分，我经常这样做），因此，我不需要更改任何现有的自动化测试：因为这些测试仅取决于组件的公共API和公共API。通常是扩展而不是更改。

我认为该政策与诸如Retesting Test Code这样的文档形成了鲜明对比，该文档表示...

“ ...单元测试...”

“ ...系统中每个类的测试类...”

“ ...测试代码/生产代码的比率...理想地被认为接近1：1的比率...”

……我想所有这些我都不同意（或者至少不练习）。

我的问题是，如果您不同意我的政策，您能解释一下原因吗？在什么情况下这种测试程度不够？

综上所述：

公共接口经过测试（和重新测试），并且很少更改（它们被添加但很少更改）

内部API隐藏在公共API的后面，可以更改而无需重写测试公共API的测试用例。

脚注：我的一些“测试案例”实际上是作为数据实现的。例如，UI的测试用例由包含各种用户输入和相应的预期系统输出的数据文件组成。测试系统意味着具有测试代码，该代码读取每个数据文件，将输入重放到系统中，并断言它获得了相应的预期输出。

尽管我很少需要更改测试代码（因为通常添加而不是更改公共API），但我确实发现有时（例如每周两次）需要更改一些现有数据文件。当我更好地更改系统输出时（即新功能改进了现有输出），可能会发生这种情况，这可能会导致现有测试“失败”（因为测试代码仅尝试断言输出未更改）。要处理这些情况，请执行以下操作：

重新运行自动测试套件，该套件带有一个特殊的运行时标志，该标志指示它不声明输出，而是将新输出捕获到新目录中

使用可视化差异工具查看哪些输出数据文件（即哪些测试用例）已更改，并验证这些更改是否良好以及新功能的预期效果

通过将新的输出文件从新目录复制到运行测试用例的目录中来更新现有测试（覆盖旧测试）

脚注：“组件”是指“一个DLL”或“一个程序集”之类的东西，其大小足以在体系结构或系统的部署图上可见，通常使用数十个或100个类来实现，并且因此与公共API只包含约1或接口少数......一些可能被分配到的开发商之一的团队（其中不同的组件被分配到不同的团队），并且将根据康威定律有相对稳定的公共API。

脚注：文章《面向对象的测试：神话与现实》说：

误解：黑匣子测试就足够了。 如果您使用类接口或规范仔细地进行了测试用例设计，则可以确信该类已被充分利用。白盒测试（查看方法的设计测试实现）违反了封装的概念。

现实：OO结构很重要，第二部分。许多研究表明，开发人员认为非常难以理解的黑盒测试套件仅在被测实现中使用了三分之一至一半的语句（更不用说路径或状态）。这有三个原因。首先，选择的输入或状态通常使用正常路径，但不强制所有可能的路径/状态。其次，仅凭黑盒测试无法揭示惊喜。假设我们已经测试了被测系统的所有指定行为。为了确信没有未指明的行为，我们需要知道黑盒测试套件是否未行使系统的任何部分。可以通过代码检测来获取此信息的唯一方法。第三，

我应该补充一点，我正在做白盒功能测试：我看到了代码（在实现中），并且编写了功能测试（驱动公共API）以行使各种代码分支（功能实现的详细信息）。

Answer 1

我的做法是通过公共API / UI测试内部。如果无法从外部访问某些内部代码，则可以重构以将其删除。

Answer 2

答案很简单：您正在描述功能测试，这是软件质量检查的重要组成部分。测试内部实现是单元测试，这是软件质量保证的另一部分，目标是不同的。因此，您会感到人们不同意您的方法。功能测试对于验证系统或子系统是否已完成预期的工作很重要。客户看到的任何内容都应通过这种方式进行测试。单元测试是为了检查您刚刚编写的10行代码是否符合预期。它使您对代码有更高的信心。两者是互补的。如果您在现有系统上工作，那么功能测试可能是第一件事。但是，一旦添加代码，对它进行单元测试也是一个好主意。

Answer 3

我的面前没有我的Lakos副本，所以我只想指出他比我解释为什么测试在所有级别上都重要的工作要好，而不是引用。仅测试“公共行为”的问题是这样的测试给您的信息很少。它会捕获许多错误（就像编译器会捕获许多错误一样），但是无法告诉您这些错误在哪里。执行不佳的单元通常会长时间返回良好的值，然后在条件发生变化时停止这样做，这是很常见的。如果对该单元进行了直接测试，则其实施不当的事实将很快得到证实。测试粒度的最佳级别是单位级别。通过其界面为每个单元提供测试。这使您可以验证并记录您对每个组件的工作方式的信念，从而允许您仅通过测试其引入的新功能来测试相关代码，从而使测试简短易达。另外，它可以使用他们正在测试的代码来进行测试。换句话说，只要您注意每个公共可见的类都有公共行为，则仅测试公共行为是正确的。