内部课程应该进行单元测试吗？

Question

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

我的同事给出的非单元测试内部课程

的要点

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

我在青睐单元测试内部课程

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

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

请注意java人员：“ internal ”是C＃中的关键字，它限制了类对程序集的可见性。在程序包/程序集之外无法访问该类。它不等同于私人课程。

Answer 1

这应该根据具体情况决定：

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

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

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

您的参数适用于第一个项目符号（共享实现）中的类，而您的同事的参数适用于第二个项目符号（私有实现）中的类。