我们正在开发一种新的API . 我的同事和我对内部课程是否应该进行单元测试有不同的看法 .
我的同事为 not unit testing internal classes 给出的分数
-
单元测试应仅针对公共类/方法编写
-
您应该能够通过公共API本身覆盖您的完整代码，包括内部类 . 如果您的内部类没有通过公共接口进行测试，这意味着有一些丢失的测试用例，或者您找到了不需要的死代码 .
-
内部类的写入单元测试可能导致冗余测试，或者可能强制编写从不需要的代码 .
我在 favor of unit testing internal classes 给出的分数
-
通过单元测试覆盖完整代码只有公共类可能很难/不切实际 . 为内部类编写单元测试确保它们至少在自己的世界中正确运行，并且我们可以进行集成测试以测试整个应用程序的正确性 .
-
即使有一些冗余单元测试，也比在顶层缺少测试用例更好 .
-
内部类是公开的，所以我们应该独立测试它们 . 如果只有一个公共类和100个内部类，则很难通过公共接口覆盖所有场景 .
我尝试在线搜索，但似乎没有关于此的最佳实践或标准意见 . 你认为一个好的方法是什么？
Note to java people: “internal”是C＃中的关键字，它将类的可见性限制为程序集 . 在程序包/程序集之外无法访问该类 . 它不等同于私人阶级 .
1 回答
这应该根据具体情况决定：
You should unit test internal classes that provide shared functionality - 库中的某些类为共享代码提供了一个位置 . 虽然它们将通过使用它们的类间接测试，但是通过额外的直接测试可以让您区分类本身的问题与类使用的问题 .
You should not unit test internal classes that could be privately nested - 某些类为单个类或单个类层次结构提供实现逻辑 . 这些类可以转换为嵌套类，但出于审美或哲学原因而保留为顶级类 . 这些类需要通过使用它们的类的公共接口进行测试 .
当您需要重构共享代码时，单元测试共享实现特别有用 . 如果您进行了重大更改，并且所有单元测试都是通过其他类间接完成的，那么最终会出现多个单元测试失败，其中没有一个指向根本原因 . 另一方面，如果您对共享实现进行了直接单元测试，则根本原因更容易检测 .
此外，通过重构使用它的类的测试，您不会失去内部类代码的覆盖范围，因为您可以直接测试类本身 .
您的参数适用于第一个项目符号（共享实现）中的类，而您的同事的参数适用于第二个项目符号（私有实现）中的类 .