内部类应该进行单元测试吗？ [关闭]

Question

我们正在开发一个新的 API。我和我的同事对于内部类是否应该进行单元测试有不同的看法。

我的同事给出的没有对内部类进行单元测试

的要点

1. 单元测试应仅针对公共类/方法编写
2. 您应该能够覆盖您的完整代码，包括通过公共 API 本身的内部类。如果您的内部类没有通过公共接口进行测试，则意味着缺少一些测试用例，或者您发现了不需要的死代码。
3. 为内部类编写单元测试可能会导致冗余测试，或者可能会强制编写从不需要的代码。

我在支持单元测试内部类

中给出的分数

1. 仅通过单元测试公共类来覆盖完整的代码可能很困难/不切实际。为内部类编写单元测试至少可以确保它们在自己的环境中正确运行，并且我们可以进行集成测试来测试整个应用程序的正确性。
2. 即使有一些冗余的单元测试，也比在顶层缺少测试用例要好。
3. 内部类对其环境是公开的，因此我们应该独立测试它们。如果只有 1 个公共类和 100 个内部类，很难通过公共接口覆盖所有场景。

我尝试在线搜索，但似乎没有关于此的最佳做法或标准意见。您认为什么是可以遵循的好方法？

java 人士注意：“internal”是 C# 中的一个关键字，它限制类对程序集的可见性。该类将无法在包/程序集之外访问。不等同于私有类。

Answer 1

这应根据具体情况决定：

• 您应该对提供共享功能的内部类进行单元测试 - 您的库中的某些类为共享代码提供了空间。虽然它们将通过使用它们的类进行间接测试，但额外的直接测试可以让您区分类本身的问题和类使用的问题。
• 您不应对可能私有嵌套的内部类进行单元测试 - 某些类为单个类或单个类层次结构提供实现逻辑。这样的类可以转换为嵌套类，但出于美学或哲学原因保留为顶级类。这些类需要通过使用它们的类的公共接口进行测试。

当您需要重构共享代码时，单元测试共享实现特别有用。如果您进行了重大更改，并且您的所有单元测试都是通过其他类间接完成的，那么您最终会遇到多个单元测试失败，而这些都没有指向根本原因。另一方面，如果您对共享实现有直接的单元测试，则更容易检测到根本原因。

此外，通过重构使用它的类的测试，您不会失去对内部类代码的覆盖，因为您可以对类本身进行直接测试。

您的论点适用于第一个要点（共享实现）的类，而您同事的论点适用于第二个要点（私有实现）的类。