非公共方法的单元测试和测试驱动开发答案

【问题标题】：Unit testing and Test Driven Development of non public methods非公共方法的单元测试和测试驱动开发
【发布时间】：2012-07-25 08:55:10
【问题描述】：

我是 TDD 概念的新手，并且刚刚开始掌握为我的应用程序的公共接口编写好的单元测试的窍门。

目前，我正在开发一个类库，其中公共接口相对较小，但在幕后的类中存在大量复杂性。此功能在内部范围的类和方法中实现，因此不可用于单元测试。我不想公开这些类和方法，因为它们不应该对消费应用程序可用，但我觉得如果不编写更具体的测试用例，我无法充分测试应用程序的所有功能。

有人可以向我解释如何完成这样的测试吗？或者我的方法有问题，我可以改变以促进更好的测试。

顺便说一句，我在 C# .NET 环境中工作，但我认为我的问题也适用于 Java 或任何数量的其他平台。

【问题讨论】：

标签： .net unit-testing testing mstest

【解决方案1】：

在 Java 中，您通常会使用类似 PowerMock 的 Whitebox 类或使用默认（包）范围来绕过访问检查。换句话说，根本没有访问修饰符。单元测试通常与被测类在同一个包中。在 .NET 中，您可能能够在内部范围内获得类似的功能，但在这种情况下，听起来您需要您的测试和被测代码位于同一个程序集中。如果这是一个问题，也许你可以让你的测试程序集成为被测代码的friend assembly。

【讨论】：

【解决方案2】：

由于您使用的是 dotnet，因此您可以将其他类设为 dll 内部，并在业务类中使用 internalsvisibleto 属性以允许 unittest-dll 访问它们。

【讨论】：

【解决方案3】：

大多数单元测试专家会告诉您，您应该只测试公共接口。但是我不同意他们的观点，因为我经常遇到类似的情况。如果您使用 C# 和支持单元测试的 Visual Studio 版本，那么您很幸运。只需单击测试-> 新建测试...，然后选择“单元测试向导”。然后选择您想要测试的任何方法（包括私有方法）。 Visual Studio 将自动为您生成单元测试。对于私有方法，它将创建名为 MyClass_Accessor 的影子类。这些类与您的原始类完全相同，但它们的私有成员是公共的。如果您更改类，这些影子类也会自动更新。

【讨论】：

【解决方案4】：

不要对私有方法进行单元测试。如果值得测试，那么值得公开或功能应该在自己的类中。似乎违反了 SOLID 原则。

【讨论】：

这似乎是一种天真的看待事物的方式。该功能分为内部可用的逻辑类。只是该功能没有对外暴露。他们有单一的职责，等等，但公开公开它自己的类中的所有内容是没有意义的。
也许另一种看待这个问题的方式是 - 如果内部类足够复杂以至于需要进行测试，您应该考虑将它们设为更高阶的类（公共），甚至将它们逻辑分组并将它们移动到一个新的大会。您应该只测试公共接口，如果这些测试太复杂而无法涵盖所有内部类，那么您就会有代码味道。这不是一件坏事！ TDD 通过识别这些东西来帮助我们推进设计。