主持人注:这里已经有39个答案了(有些已经删除了)。在你发表你的答案之前，考虑一下你是否可以为讨论添加一些有意义的东西。你很可能只是在重复别人已经说过的话。
我偶尔发现自己需要将类中的私有方法设为public，只是为了为它编写一些单元测试。
通常这是因为该方法包含类中其他方法之间共享的逻辑，并且单独测试逻辑更整洁，或者另一个原因可能是我想测试同步线程中使用的逻辑，而不必担心线程问题。
其他人发现他们这样做是因为我不喜欢吗?我个人认为，公开一个方法的好处超过了它在类之外没有提供任何服务的问题……
更新
谢谢大家的回答，似乎引起了大家的兴趣。我认为普遍的共识是测试应该通过公共API进行，因为这是使用类的唯一方式，我非常同意这一点。在我上面提到的几个案例中，我会这样做，这是不常见的情况，我认为这样做的好处是值得的。
然而，我可以看到，每个人都指出它不应该真的发生。再仔细想想，我觉得改变你的代码来适应测试是一个坏主意——毕竟我认为测试在某种程度上是一个支持工具，而改变一个系统来“支持一个支持工具”是明显的坏做法。
当前回答
我通常将测试类保持在与测试类相同的项目/程序集中。 这样，我只需要内部可见性来使函数/类可测试。
这在一定程度上使您的构建过程变得复杂，需要过滤掉测试类。 我通过将所有测试类命名为TestedClassTest并使用正则表达式筛选这些类来实现这一点。
当然，这只适用于你的问题中的c# / .NET部分
其他回答
实际上，有些情况下你应该这样做(例如，当你实现一些复杂的算法时)。只做package-private，这就足够了。 但在大多数情况下，你可能有太复杂的类，这就需要把逻辑分解到其他类中。
就我个人而言，我在测试私有方法时也有同样的问题，这是因为一些测试工具是有限的。 如果你的设计被有限的工具所驱动，而这些工具并不能满足你的需求，那么你需要改变的是工具而不是设计。 因为你要求使用c#，我不能提出好的测试工具，但是对于Java，有两个强大的工具:TestNG和PowerMock，并且你可以找到对应的。net平台的测试工具
在您的更新中，您说使用公共API进行测试很好。 这里实际上有两所学校。
黑盒测试 黑盒学派认为，类应该被视为一个黑盒，没有人可以看到其中的实现。测试这一点的唯一方法是通过公共API——就像类的用户将使用它一样。 白盒测试。 白盒学派认为自然地使用关于类实现的知识，然后测试类以了解它应该工作。
在这次讨论中我真的不能支持任何一方。我只是想知道有两种不同的方法来测试一个类(或库或其他)会很有趣。
在我看来，在编写测试时，你不应该对你的类内部是如何实现的做深入的假设。您可能希望稍后使用另一个内部模型对其进行重构，但仍然保证与以前的实现相同。
记住这一点，我建议你把重点放在测试你的契约仍然存在，不管你的类目前有什么内部实现。基于属性的公共api测试。
我经常会在类中添加类似validate、verify、check等方法，这样就可以调用它来测试对象的内部状态。
有时这个方法被包装在一个ifdef块中(我主要是用c++写的)，这样它就不会被编译发布。但是在发行版中，提供遍历程序对象树检查内容的验证方法通常是有用的。
