很多时候我发现自己在将方法设为私有以防止有人在没有意义的上下文中调用它（或会搞砸所涉及对象的内部状态）或将方法设为公开（或通常是内部的），以便将其暴露给单元测试程序集。我只是想知道 Stack Overflow 社区如何看待这种困境？
所以我想问题确实是，是专注于可测试性还是保持适当的封装更好？
最近我一直倾向于可测试性，因为大部分代码只会被一小部分开发人员利用，但我想我会看看其他人的想法？
【问题讨论】：
标签： c# unit-testing
不能更改客户或用户可以看到的方法的可见性。这样做很丑陋，是一种黑客行为，暴露了任何愚蠢的用户都可以尝试使用并炸毁您的应用程序的方法……这是您不需要的责任。
您使用的是 C# 是吗？查看internals visible to 属性类。 您可以将可测试方法声明为内部方法，并允许您的单元测试程序集访问您的内部方法。
【讨论】：
这取决于方法是否是公共 API 的一部分。如果方法不属于公共 API 的一部分，但在同一程序集中的其他类型中被公开调用，请使用 internal，为您的单元测试程序集加好友，然后对其进行单元测试。
但是，如果该方法不是/不应该是公共 API 的一部分，并且它未被程序集内部的其他类型调用，则不要直接对其进行测试。它应该是受保护的或私有的，并且只能通过对您的公共 API 进行单元测试来间接测试它。如果您为您的类型的非公共（或应该是非公共）成员编写单元测试，则您将测试代码绑定到内部实现细节。
这是一种糟糕的耦合，增加了您需要的单元测试数量，增加了短期（更多单元测试）和长期（更多测试维护和修改以响应重构内部实现）的工作量细节）。测试非公共成员的另一个问题是您测试可能实际上不需要或使用的代码。找到死代码的一个好方法是当你的公共 API 被 100% 覆盖时，任何单元测试都没有覆盖它。删除死代码是保持代码库精简和平均的好方法，如果您不小心将哪些内容放入公共 API 以及您对代码的哪些部分进行单元测试，则这是不可能的。
编辑： 作为一个快速的附加说明......通过正确设计的公共 API，您可以非常有效地使用像 Microsoft PEX 这样的工具来自动生成全面覆盖的单元测试，以测试代码的每个执行路径。结合一些涵盖关键行为的手动编写测试，任何未涵盖的内容都可以视为死代码并被删除，您可以大大缩短单元测试过程。
【讨论】：
这是一个普遍的想法。
通常最好通过测试调用私有方法的公共方法来测试私有方法（因此您不必显式测试私有方法）。但是，我知道有时您确实想测试这些私有方法。
this question (Java) 和 this question (.NET) 的答案应该会有所帮助。
回答这个问题：不，您不应该为了测试而更改方法可见性。你通常不应该测试私有方法，当你这样做时，有更好的方法来做。
【讨论】：
总的来说，我同意@jrista。但是，像往常一样，这取决于。
在尝试使用遗留代码时，关键是对其进行测试。之后，您可以为新功能和现有错误添加测试，重构以改进设计等。如果没有测试，这是有风险的。遗留代码往往充满依赖关系，而且通常极难接受测试。
在Working Effectively with Legacy Code 中，Michael Feathers 提出了多种用于测试代码的技术。其中许多技术涉及破坏封装或使设计复杂化，而作者对此很清楚。一旦测试到位，就可以安全地改进代码。
所以对于遗留代码，做你必须做的。
【讨论】：
在 .NET 中，您应该使用访问器进行单元测试，而不是使用 InternalsVisibleTo 属性。访问器允许您访问类中的任何方法，即使它是私有的。它们甚至允许您使用空的模拟派生对象来测试抽象类（参见“PrivateObject”类）。
基本上，在您的测试项目中，您使用访问器类而不是带有您要测试的方法的实际类。访问器类与“真实”类相同，只是所有内容对您的测试项目都是公开的。 Visual Studio 可以为您生成访问器。
永远不要让类型更明显以方便单元测试。
IMO 说您不应该对私有方法进行单元测试是错误的。单元测试对于回归测试具有特殊的价值，没有理由不应该使用细粒度单元测试对私有方法进行回归测试。
【讨论】：